Есть ли преимущество в том, чтобы не выравнивать раздел по индексу?

9

У меня есть привилегия управлять большой секционированной таблицей OLAP. Просматривая эту таблицу, я заметил, что один из индексов не соответствует схеме разбиения. Поскольку автор недоступен, а тщательно продуманные поиски в Google не дали никаких полезных результатов, я не уверен, было ли это намеренным или случайным.

Есть ли причина не разделять выравнивание индекса на SQL Server 2008?

— Робин
источник

1

Возможно. Запросите статистику использования индекса, чтобы узнать, используется ли этот индекс. Если это так, используйте расширенные события или трассировку на стороне сервера, чтобы определить, какие запросы попадают в этот индекс. Если бы они работали лучше с индексом, выровненным по разделам, отлично Если нет, проверьте, действительно ли им нужны невыровненные секционированные индексы. Если они этого не сделают, я бы сказал, что все равно выровняйте разделы, так как будущие запросы могут воспользоваться этим. Конечно, если цена / усилие / отключение слишком высоки, не надо.

— Али Разеги

Из того, что я прочитал, лучшая практика для индексации многораздельной таблицы - это согласование индекса со схемой разделения. Эта конкретная таблица заставила меня задуматься о том, что я хочу понять вариант использования, чтобы не согласовать индекс со схемой секционирования. Я не пытаюсь решить конкретную проблему, поэтому у меня нет запроса, который нужно проанализировать.

— Робин

Еще одна причина для создания невыровненного индекса - это уникальный индекс (включая первичный ключ или ограничение уникальности), который не включает столбец разделения. В этом случае индекс не должен быть разделен вообще или разделен с использованием другой функции / схемы.

— Дан Гузман

11

Основное преимущество не разбиение (не уникальный) индекса на секционированном базовый объекте является то , что она работает вокруг давнего ограничения оптимизатора запросов , связанное с упорядоченными запросами данных , такие как MIN, MAXили TOP (n)запросы.

На секционированного индекса, оптимизатор вообще не может перевести MIN, MAXили TOP (n)в одной и той же операции за перегородкой , с последующей конечной глобальной совокупности более частичных агрегатов за перегородкой. Вместо этого оптимизатор выбирает план выполнения, который сканирует все разделы индекса. Исключением является единственный случай, когда для столбца разделения задается агрегатная или верхняя операция.

Я должен упомянуть, что есть также очень веские причины, чтобы не иметь никаких невыровненных индексов. Выбор использования невыровненного индекса должен быть очень осознанным. Я делал это сам (редко) в прошлом, но в очень специфических обстоятельствах, когда выгоды явно перевешивали затраты, или другой разумной альтернативы не было.

Статья Ицик Бен-Гана, объясняющая проблему.

— Пол Уайт 9
источник

3

Существует очевидная проблема вокруг некоторых ограничений (например, уникальных), требующих невыровненного индекса.

Помимо этого, невыровненные индексы имеют большую стоимость (в первую очередь они не позволяют многим параллельным операторам переходить от потока к разделу, а альтернативы требуют много памяти), и поэтому я настоятельно рекомендую не использовать такие индексы. Даже с учетом случаев, перечисленных Полом, я бы все же советовал не относящиеся к размеру индексы.

— Ремус Русану
источник

1

Да. Выбор внеблокового индекса должен быть очень осознанным выбором. Я делал это сам (редко) в прошлом, но в очень специфических обстоятельствах, когда выгоды перевешивали затраты.

— Пол Уайт 9

2

Невыравниваемые индексы сводят на нет основное преимущество разделения, заключающееся в переключении разделов. Если вы не зависите от этого и делите разделы по другим причинам (другое хранилище, разделы только для чтения, инкрементная статистика, ...), тогда продолжайте и создайте невыровненный indexex.

Невыравниваемые индексы полезны, потому что с их помощью можно применять уникальные ограничения для всей таблицы. Кроме того, для невыровненных индексов не требуется, чтобы ключ разделения был неявным префиксом поиска. Представьте, что у вас есть 10000 разделов и запросы не основаны на ключе разделения. В этом случае план выполнения должен будет найти 10000 разделов, если индекс был выровнен. Другие ответы имеют дополнительные примеры.

— USR
источник