Кластерный индекс SQL Server - вопрос о порядке индекса

Question

У меня есть таблица примерно так:

keyA keyB data

keyA и keyB вместе являются уникальными, являются первичным ключом моей таблицы и составляют кластерный индекс.

Существует 5 возможных значений keyB, но неограниченное количество возможных значений keyA ,. keyB обычно увеличивается.

Например, следующие данные можно упорядочить двумя способами в зависимости от того, какой ключевой столбец упорядочен первым:

keyA keyB data
A    1    X
B    1    X
A    3    X
B    3    X
A    5    X
B    5    X
A    7    X
B    7    X

или

keyA keyB data
A    1    X
A    3    X
A    5    X
A    7    X
B    1    X
B    3    X
B    5    X
B    7    X

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

Answer 1

Сначала вы должны упорядочить составной кластерный индекс с наиболее селективным столбцом. Это означает столбец с наиболее различимыми значениями по сравнению с общим числом строк.

«Индексы B * TREE повышают производительность запросов, которые выбирают небольшой процент строк в таблице». http://www.akadia.com/services/ora_index_selectivity.html?

Эта статья для Oracle, но все еще актуальна.

Кроме того, если у вас есть запрос, который выполняется постоянно и возвращает мало полей, вы можете рассмотреть возможность создания составного индекса, который содержит все поля - ему не нужно будет обращаться к базовой таблице, но вместо этого он будет извлекать данные из индекса.

Комментарий ligget78 о том, что необходимо упомянуть первый столбец в составном индексе, важно помнить.

Answer 2

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

Это может иметь значение с точки зрения производительности, конечно, зависит от вашего запроса. Например, если у вас есть индекс (keyA, keyB), а запрос выглядит как WHERE keyB = ... (без упоминания keyA), тогда индекс использовать нельзя.

Answer 3

Как уже говорили другие, порядок основан на том, как вы указываете его в сценарии создания индекса (или в ограничении PK). Однако в кластеризованных индексах есть одна вещь, о которой нужно помнить.

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

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

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

Answer 4

На всякий случай, если это не очевидно: порядок сортировки вашего индекса не обещает много о порядке сортировки , в результате чего получается запрос .

В ваших запросах вы все равно должны добавить

ORDER BY KeyA, KeyB

или

ORDER BY KeyB, KeyA

Оптимизатор может с удовольствием найти данные, уже физически упорядоченные в индексе, по своему желанию и сэкономить некоторое время, но каждый запрос, который должен доставлять данные в определенном порядке, должен иметь в конце предложение ORDER BY. Без упорядочения по SQL Server не дает никаких обещаний относительно порядка набора записей или даже того, что он будет возвращаться в том же порядке от запроса к запросу.

Answer 5

Помните, что кластерный индекс - это физический порядок, в котором таблица хранится на диске.

Таким образом, если ваш кластерный индекс определен как ColA, запросы ColB будут выполняться быстрее, если порядок в том же порядке, что и ваш кластерный индекс. Если SQL должен упорядочить B, A, для достижения правильного порядка потребуется сортировка после выполнения.

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

Реально, ваш кластеризованный индекс должен представлять порядок, в котором данные, скорее всего, будут доступны, а также поддерживать тонкий баланс затрат на ввод / обновление IO. Если ваш кластеризованный индекс таков, что вы постоянно вставляете его в середину страниц, вы можете потерять там производительность.

Как уже говорили другие, без знания длины таблицы, размеров столбцов и т. Д. Правильного ответа не существует. Метод проб и ошибок с большой дозой тестирования - ваш лучший выбор.

Answer 6

Я считаю, что SQL Server заказывает именно так, как вы говорите. Предполагается, что вы лучше знаете, как получить доступ к вашему индексу.

В любом случае, я бы сказал, что по возможности лучше указать, что именно вы хотите, а не надеяться, что база данных это выяснит.

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

Answer 7

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

http://ashishkhandelwal.arkutil.com/sql-server/quick-and-short-database-indexes/

• Рекомендации по использованию индексов
• Как получить лучшие показатели формы индексов
• Кластерный индекс Соображения
• Замечания по некластерным индексам

Я уверен, что это поможет вам при планировании индекса.

Answer 8

Вы указываете столбцы в том порядке, в котором вы обычно хотите, чтобы они сортировались в отчетах и ​​запросах.

Хотя я бы с осторожностью относился к созданию многоколоночного кластерного индекса. В зависимости от его ширины вы можете оказать огромное влияние на размер любых других создаваемых вами индексов, поскольку все некластеризованные индексы содержат в себе значение кластеризованного индекса. Кроме того, строки должны быть переупорядочены, если значения часто меняются, и, по моему опыту, несуррогатные ключи имеют тенденцию меняться чаще. Поэтому создание этого кластерного вице-некластеризованного индекса может потребовать гораздо больше времени для ресурсов сервера, если у вас есть значения, которые могут измениться. Я не говорю, что вы не должны этого делать, поскольку я не знаю, какой тип данных в действительности содержатся в ваших столбцах (хотя я подозреваю, что они более сложные, чем A1, a2 и т. Д.); Я говорю, что вам нужно подумать о последствиях этого. Вероятно, было бы неплохо тщательно прочитать BOL о кластеризованных вице-некластеризованных индексах, прежде чем делать это.

Answer 9

Лучшее, что вы можете сделать, это попробовать оба решения и измерить время выполнения.

По моему опыту, индексная настройка почти точна.

Возможно, было бы лучше иметь keyB перед keyA в порядке столбцов индекса