Одной из причин предпочтения INCLUDE над ключевыми столбцами , если вам не нужен этот столбец в ключе , является документация. Это значительно упрощает развитие индексов в будущем.
Учитывая ваш пример:
CREATE INDEX idx1 ON MyTable (Col1) INCLUDE (Col2, Col3)
Этот индекс лучше всего подходит, если ваш запрос выглядит следующим образом:
SELECT col2, col3
FROM MyTable
WHERE col1 = ...
Конечно, вам не следует помещать столбцы в INCLUDE, если вы можете получить дополнительную выгоду от их наличия в ключевой части. Оба следующих запроса на самом деле предпочли бы столбец col2 в ключе индекса.
SELECT col2, col3
FROM MyTable
WHERE col1 = ...
AND col2 = ...
SELECT TOP 1 col2, col3
FROM MyTable
WHERE col1 = ...
ORDER BY col2
Давайте предположим, что это , а не , и у нас есть col2 в предложении INCLUDE, потому что его просто нет в древовидной части индекса.
Перемотка вперед на несколько лет.
Вам нужно настроить этот запрос:
SELECT TOP 1 col2
FROM MyTable
WHERE col1 = ...
ORDER BY another_col
Для оптимизации этого запроса будет полезен следующий индекс:
CREATE INDEX idx1 ON MyTable (Col1, another_col) INCLUDE (Col2)
Если вы проверите, какие индексы у вас уже есть в этой таблице, ваш предыдущий индекс все еще может быть там:
CREATE INDEX idx1 ON MyTable (Col1) INCLUDE (Col2, Col3)
Теперь вы знаете, что Col2 и Col3 не являются частью дерева индексов и, таким образом, не используются для сужения диапазона индекса чтения и для упорядочения строк. Довольно безопасно добавить another_column в конец ключевой части индекса (после col1). Существует небольшой риск что-либо сломать:
DROP INDEX idx1 ON MyTable;
CREATE INDEX idx1 ON MyTable (Col1, another_col) INCLUDE (Col2, Col3);
Этот индекс станет больше, что по-прежнему сопряжено с некоторыми рисками, но, как правило, лучше расширять существующие индексы, чем вводить новые.
Если бы у вас был индекс без INCLUDE, вы не могли бы знать, какие запросы вы бы разбили, добавив another_col сразу после Col1.
CREATE INDEX idx1 ON MyTable (Col1, Col2, Col3)
Что произойдет, если вы добавите another_col между Col1 и Col2? Будут ли страдать другие запросы?
Существуют и другие "преимущества" INCLUDE по сравнению с ключевыми столбцами , если вы добавляете эти столбцы только для того, чтобы избежать их извлечения из таблицы . Тем не менее, я считаю аспект документации самым важным.
Чтобы ответить на ваш вопрос:
Какие рекомендации вы бы предложили при определении, следует ли создавать индекс покрытия с предложением INCLUDE или без него?
Если вы добавляете столбец в индекс с единственной целью, чтобы этот столбец был доступен в индексе без посещения таблицы, поместите его в предложение INCLUDE.
Если добавление столбца к ключу индекса приносит дополнительные преимущества (например, для order by или потому, что это может сузить диапазон индекса чтения), добавьте его к ключу.
Более подробное обсуждение можно прочитать здесь:
https://use -the-index-luke.com / блог / 2019-04 / include-колонки-в-ВТКЕЕ-индексы