Правила выбора столбца некластеризованного индекса покрытия

Question

У меня есть таблица с примерно 19 столбцами, которая содержит достаточно большой объем данных и в первую очередь запрашивается для получения данных с использованием операторов выбора, основанных на предложении «различное». Поскольку эта таблица в первую очередь запрашивается для получения данных, я думал о создании некластеризованных индексов, основанных на различных предложениях where, используемых в запросах. Кроме того, все запросы get возвращают все столбцы таблицы как часть списка выбора. Основываясь на информации выше, у меня есть два вопроса для выбора индексов:

1. предположим, что у нас есть следующие SP, которые запрашивают как:

   where [col_a] = {value} and [col_b] = {value}
   
         [col_b] = {value} and [col_a] = {value}
   
         [col_a] = {value} and [col_c] = {value} and [col_d] = {value}
   
         [col_a] = {value} and [col_c] = {value}
   

   Я создал следующие некластеризованные индексы для таблицы как

   [col_a] и [col_b] -> Будет ли первый ИП все еще использовать этот индекс в качестве заказы отменены

   [col_a] и [col_c] и [col_d] -> Будет ли последний ИП использовать этот индекс так как первые два столбца совпадают с порядком

   Кроме того, следует ли нам продолжить и попытаться определить некластеризованные индексы на основе предложений filter / join для get SP в таблице?

2. Поскольку список выбора во всех SP возвращает весь список столбцов, я добавил все столбцы таблицы как включенные столбцы в некластеризованные индексы (охватывающий индекс), чтобы избежать поиска закладок. Правильный ли этот подход? Каковы значения пространства в этом случае, поскольку мы храним все столбцы таблицы как часть определения индекса?

Answer 1

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

Что касается индекса, чтобы помочь JOIN, да, есть , как правило, рекомендуется.

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

Наконец, обратите внимание, что некоторые СУБД могут использовать объединение индексов. Это может означать, что несколько простых или более простых индексов почти так же хороши, как составной / покрывающий индекс. Но в большинстве случаев при рассмотрении того, что индексировать, необходимо учитывать предложение WHERE и JOIN одновременно.

Это потому, что основной характеристикой индекса является порядок записей. Идеальный сценарий - это иметь все интересующие записи в одном последовательном блоке (после того, как предложение WHERE и JOIN отфильтровали его), и в порядке, подходящем для последующих JOIN или GROUP BY. В действительности вы стремитесь к тому, чтобы данные находились в как можно меньшем количестве последовательных кластеров и как можно лучше соответствовали порядку. Тогда пусть оптимизатор СУБД сделает все остальное:)

Answer 2

[col_a] и [col_b]
Будет ли первый ИП все еще использовать этот индекс как заказы отменены

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

Если у вас есть индекс (col_a, col_b), его можно использовать, если вы укажете:

• просто col_a
• и col_a и col_b (порядок не имеет значения)

, но нельзя использовать для запроса, который задает просто col_b (но не col_a). Чтобы быть рассмотренным для использования, необходимо использовать / определить n самых левых столбцов (n> = 1) - в любом порядке.

[col_a] и [col_c] и [col_d]
Будет ли последний ИП использовать этот индекс так как первые два столбца совпадают с порядком

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

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