SQL Server: как тип индекса влияет на производительность объединения?

Question

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

• кластерный индекс.
• некластеризованный индекс.
• кластеризованный или некластеризованный индекс с дополнительными столбцами, которые могут не участвовать в объединении.

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

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

Answer 1

В дополнение к ответу Гарета Саула есть небольшое уточнение:

Некластеризованные индексы повторяют включенные поля, с указателем на строки , которые имеют это значение.

Этот указатель на фактическое значение данных является столбцом (или набором столбцов), который находится в вашем ключе кластеризации.

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

Эта функция «указатель поиска является ключом кластеризации» была в SQL Server начиная с версии 7, как Ким Трипп объяснит здесь более подробно :

Что такое кластерный индекс?

В SQL Server 7.0 и выше внутренние зависимости от Ключ кластеризации ИЗМЕНЕН. (Да это так важно знать, что вещи изменились в 7.0 ... почему? Потому что есть еще некоторые люди там, которые не осознать, как РАДИКАЛ изменения произошло во внутренних органах (по отношению к ключ кластеризации) в SQL Server 7.0).

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

Answer 2

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

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

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

Answer 3

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

Это создаст остовный индекс, означающий, что все поля, которые требует SQL, находятся в одном индексе.

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

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

Answer 4

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

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

Полезно обратить внимание на порядок, в котором происходят ваши объединения - последовательность столбцов в вашем индексе должна соответствовать этому. Помните, что механизм SQL может оптимизировать и переупорядочить ваш запрос внутренне - профилирование может быть полезным.

В большинстве случаев вы можете просто использовать помощник по настройке ядра СУБД - рекомендации, которые он дает, в значительной степени соблюдаются.