Несколько индексов против Многоколонных индексов

Я только что добавлял индекс в таблицу в SQL Server 2005, и это заставило меня задуматься. В чем разница между созданием 1 индекса и определением нескольких столбцов по 1 индексу на столбец, который вы хотите индексировать.

есть ли определенные причины, по которым один должен использоваться над другим?

Create NonClustered Index IX_IndexName On TableName
(Column1 Asc, Column2 Asc, Column3 Asc)

и

Create NonClustered Index IX_IndexName1 On TableName
(Column1 Asc)

Create NonClustered Index IX_IndexName2 On TableName
(Column2 Asc)

Create NonClustered Index IX_IndexName3 On TableName
(Column3 Asc)

6 ответов


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

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

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

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

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

штат, округ, zip.

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

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

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

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

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

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


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

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

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

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


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

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

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


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


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

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

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

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


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

  1. индекс зарабатывает одну звезду, если он помещает соответствующие строки рядом друг с другом
  2. вторая звезда, если ее строки отсортированы в порядке запроса
  3. последняя звезда, если она содержит все столбцы, необходимые для запроса

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