Множественные индексы против многоколоночных индексов

да. Я рекомендую вам проверить Статьи Кимберли Трипп об индексировании.

Если индекс «покрывает», тогда нет необходимости использовать что-либо, кроме индекса. В SQL Server 2005 вы также можете добавить в индекс дополнительные столбцы, которые не являются частью ключа, что может устранить переходы к остальной части строки.

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

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

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

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

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

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

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

SELECT *
FROM TableName
WHERE Column1=1 AND Column2=2 AND Column3=3

Это можно найти напрямую, используя многостолбцовый индекс. С другой стороны, можно использовать не более одного индекса с одним столбцом (ему нужно будет найти все записи, имеющие Column1 = 1, а затем проверить Column2 и Column3 в каждой из них).

Я согласен с Кейд Ру.

Эта статья должна направить вас на верный путь:

• Индексы в SQL Server 2005/2008 - передовой опыт, часть 1
• Индексы в SQL Server 2005/2008 - Часть 2 - Внутреннее устройство

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

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

например представьте, что вы ищете в таблице по трем столбцам

состояние, округ, почтовый индекс.

• иногда вы ищете только по штатам.
• иногда вы выполняете поиск по штатам и округам.
• вы часто выполняете поиск по штатам, округам, почтовым индексам.

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

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

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

Кстати, Мы можем воспользоваться тем фактом, что при многоколоночной индексации первый столбец индекса всегда можно использовать для поиска., и когда вы выполняете поиск только по «состоянию», он эффективен, но все же не так эффективен, как одноколоночный индекс в «состоянии».

Я предполагаю, что ответ, который вы ищете, заключается в том, что он зависит от ваших предложений where ваших часто используемых запросов, а также от вашей группы by.

Статья очень поможет. :-)

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