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

Question

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

keyA keyB data 

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

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

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

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

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

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

Может быть, имея KEYB перед тем KEYA в порядке индекса столбца будет лучше

Answer 3

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

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

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

Answer 4

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

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

Answer 5

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

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

Answer 6

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

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

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

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

Answer 7

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

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

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

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

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

Answer 8

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

В запросах, необходимо еще добавьте

ORDER BY KeyA, KeyB 

или

ORDER BY KeyB, KeyA 

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

Answer 9

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

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

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

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