Несколько индексов против многоколоночных индексов
Я только что добавлял индекс в таблицу в 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 ответов:
Я согласен с Кейд Ру.
эта статья должна вывести вас на правильный путь:
- индексы в SQL Server 2005/2008-рекомендации, Часть 1
- индексы в SQL Server 2005/2008-Часть 2-внутренние устройства
следует отметить, что кластеризованные индексы должны иметь уникальный ключ (столбец идентификаторов, который я бы рекомендовал) в качестве первого столбца. В основном это помогает вставлять данные в конец индекса и не вызывает много дисковых IO и разбиений страниц.
во-вторых, если вы создаете другие индексы на ваших данных, и они построены умно, они будут использоваться повторно.
например, представьте, что вы ищете таблицу на три столбца
штат, округ, zip.
- вы иногда ищете только по состоянию.
- вы иногда ищете по штату и округу.
- вы часто ищете по штату, округу, zip.
затем индекс с состоянием, округом, zip. будет использоваться во всех трех из этих поисков.
Если вы будете искать только по zip довольно много, то приведенный выше индекс не будет использоваться (SQL Server в любом случае), поскольку zip является третьей частью этого индекса, и оптимизатор запросов не увидит, что этот индекс полезен.
затем вы можете создать индекс только на Zip, который будет использоваться в этом случае.
Я думаю, что ответ, который вы ищете, заключается в том, что он зависит от ваших предложений where ваших часто используемых запросов, а также вашей группы by.
статья очень поможет. : -)
да. Я рекомендую вам проверить статьи Кимберли Трипп об индексации.
Если индекс "покрывает", то нет необходимости использовать что-либо, кроме индекса. В SQL Server 2005 можно также добавить в индекс дополнительные столбцы, которые не являются частью ключа, что позволяет исключить переходы к остальной части строки.
имея несколько индексов, каждый на одном столбце может означать, что только один индекс используется вообще - вам придется ссылаться на выполнение планируйте посмотреть, какие эффекты предлагают различные схемы индексирования.
вы также можете использовать мастер настройки, чтобы определить, какие индексы сделают данный запрос или рабочую нагрузку лучше всего.
многоколоночный индекс может использоваться для запросов, ссылающихся на все столбцы:
SELECT * FROM TableName WHERE Column1=1 AND Column2=2 AND Column3=3Это можно посмотреть непосредственно с помощью индекса нескольких столбцов. С другой стороны, можно использовать не более одного одностолбцового индекса (он должен будет искать все записи, имеющие Column1=1, а затем проверять Column2 и Column3 в каждом из них).
один элемент, который, кажется, был пропущен, - это звездные преобразования. Пересечение Индекса операторы разрешают предикат путем вычисления набора строк, попадающих в каждый из предикатов, прежде чем какой-либо ввод-вывод будет выполнен в таблице фактов. В звездной схеме вы индексируете каждый отдельный ключ измерения, и оптимизатор запросов может решить, какие строки выбрать с помощью вычисления пересечения индексов. Индексы на отдельных столбцах дают лучшую гибкость для этого.
Если у вас есть запросы, которые будут часто использовать относительно статический набор столбцов, создание одного индекса покрытия, который включает их все, значительно повысит производительность.
помещая несколько столбцов в индекс, оптимизатор будет иметь доступ к таблице только непосредственно, если столбец не находится в индексе. Я использую их много в хранилище данных. Недостатком является то, что это может стоить много накладных расходов, особенно если данные очень летучий.
создание индексов для отдельных столбцов полезно для операций поиска, часто встречающихся в системах OLTP.
вы должны спросить себя, почему вы индексирования столбцов и как они будут использоваться. Запустите некоторые планы запросов и посмотрите, когда к ним обращаются. Настройка индекса-это такой же инстинкт, как и наука.
книга Лахденмаки и Лича "проектирование индексов реляционных баз данных и оптимизаторы" представляет трехзвездочную систему для оценки того, насколько подходит индекс для запроса.
- индекс получает одну звезду, если он помещает соответствующие строки рядом друг с другом
- вторая звезда, если ее строки отсортированы в порядке запроса
- последняя звезда, если она содержит все столбцы, необходимые для запроса
создать несколько индексов для столбцов, эта стратегия индексирования часто приводит к тому, что люди дают неопределенные, но авторитетные советы, такие как "создание индексов по столбцам, которые появляются в предложении WHERE."Этот совет очень неправильный. Это приведет в лучшем случае к однозвездочным индексам. Эти индексы могут быть на много порядков медленнее, чем действительно оптимальные индексы. Иногда, когда вы не можете создать трехзвездочный индекс, гораздо лучше игнорировать предложение WHERE и обратить внимание на оптимальный порядок строк или создать индекс покрытия вместо.
Comments