Здравствуйте, IT, Вы писали:

IT>Если индекс не партиционированный, то вроде всё работает как обычно и деградация производительности неизбежно наступает с ростом объёма данных. Тоже самое происходит, если все индексы/таблица партеционированы, но фильтр по ts в запросах не используется. Даже если это поле завязано через джоины с другими таблицами, но явно не указано в фильтре, то оптимизатор всё равно не может разобраться. По крайней мере это справедливо для SQL Server 2012. Так что, исходя из моего личного опыта, единственный правильный способ использования партиционирования — это всегда использовать соответсвтующее поле в фильтре для всех партиционированнх таблиц. Иначе после (для моего железа) 150M записей в таблице начинается деградация. А с фильтром даже миллиарды записей никак на производительность не влияют.

Надо будет потестировать. Когда я экспериментировал, вроде сканирование всех разделов шло параллельно. Формально скорость снижается, но насколько — надо смотреть.

S>>Ээээээ... некластерные индексы при наличии кластерного используют не абсолютные ссылки, а ключ кластерного индекса. Потому и возник вопрос.

IT>Ну может быть. Я в таких дебрях не разбирался. Хотя, если у меня кластерный индекс содержит 15 полей, то как-то это не очень.

Тогда все 15 полей попадут во все некластерные индексы автоматически.

Здравствуйте, IT, Вы писали:

IT>Если индекс не партиционированный, то вроде всё работает как обычно и деградация производительности неизбежно наступает с ростом объёма данных. Тоже самое происходит, если все индексы/таблица партеционированы, но фильтр по ts в запросах не используется. Даже если это поле завязано через джоины с другими таблицами, но явно не указано в фильтре, то оптимизатор всё равно не может разобраться. По крайней мере это справедливо для SQL Server 2012. Так что, исходя из моего личного опыта, единственный правильный способ использования партиционирования — это всегда использовать соответсвтующее поле в фильтре для всех партиционированнх таблиц. Иначе после (для моего железа) 150M записей в таблице начинается деградация. А с фильтром даже миллиарды записей никак на производительность не влияют.

Надо будет потестировать. Когда я экспериментировал, вроде сканирование всех разделов шло параллельно. Формально скорость снижается, но насколько — надо смотреть.

S>>Ээээээ... некластерные индексы при наличии кластерного используют не абсолютные ссылки, а ключ кластерного индекса. Потому и возник вопрос.

IT>Ну может быть. Я в таких дебрях не разбирался. Хотя, если у меня кластерный индекс содержит 15 полей, то как-то это не очень.

Тогда все 15 полей попадут во все некластерные индексы автоматически.
Поясню — если все эти 15 полей находятся в ключе индекса. Что весьма странный сценарий. А вот запихивать в ключ длинное текстовое поле точно не стоит.