Um motivo para preferir INCLUDE
as colunas-chave, se você não precisar dessa coluna na chave, é a documentação. Isso torna os índices em evolução muito mais fáceis no futuro.
Considerando o seu exemplo:
CREATE INDEX idx1 ON MyTable (Col1) INCLUDE (Col2, Col3)
Esse índice é melhor se a sua consulta estiver assim:
SELECT col2, col3
FROM MyTable
WHERE col1 = ...
É claro que você não deve colocar colunas INCLUDE
se puder obter um benefício adicional por tê-las na parte principal. Na verdade, as duas consultas a seguir preferem a col2
coluna na chave do índice.
SELECT col2, col3
FROM MyTable
WHERE col1 = ...
AND col2 = ...
SELECT TOP 1 col2, col3
FROM MyTable
WHERE col1 = ...
ORDER BY col2
Vamos assumir que esse não é o caso e temos col2
a INCLUDE
cláusula porque simplesmente não há benefício em tê-la na parte da árvore do índice.
Avanço rápido em alguns anos.
Você precisa ajustar esta consulta:
SELECT TOP 1 col2
FROM MyTable
WHERE col1 = ...
ORDER BY another_col
Para otimizar essa consulta, o seguinte índice seria ótimo:
CREATE INDEX idx1 ON MyTable (Col1, another_col) INCLUDE (Col2)
Se você verificar quais índices você já possui nessa tabela, o índice anterior ainda pode estar lá:
CREATE INDEX idx1 ON MyTable (Col1) INCLUDE (Col2, Col3)
Agora você sabe disso Col2
e Col3
não faz parte da árvore de índices e, portanto, não é usado para restringir o intervalo do índice de leitura nem para ordenar as linhas. É bastante seguro adicionar another_column
o final da parte-chave do índice (depois col1
). Há pouco risco de quebrar qualquer coisa:
DROP INDEX idx1 ON MyTable;
CREATE INDEX idx1 ON MyTable (Col1, another_col) INCLUDE (Col2, Col3);
Esse índice se tornará maior, o que ainda apresenta alguns riscos, mas geralmente é melhor estender os índices existentes em comparação com a introdução de novos.
Se você tivesse um índice sem INCLUDE
, não saberia quais consultas interromperia adicionando another_col
logo em seguida Col1
.
CREATE INDEX idx1 ON MyTable (Col1, Col2, Col3)
O que acontece se você adicionar another_col
entre Col1
e Col2
? Outras consultas sofrerão?
Existem outros "benefícios" de INCLUDE
colunas-chave vs. se você adicionar essas colunas apenas para evitar buscá-las na tabela . No entanto, considero o aspecto da documentação o mais importante.
Para responder sua pergunta:
que diretrizes você sugeriria para determinar se criaria um índice de cobertura com ou sem a cláusula INCLUDE?
Se você adicionar uma coluna ao índice com o único objetivo de disponibilizá-la no índice sem visitar a tabela, coloque-a na INCLUDE
cláusula
Se adicionar a coluna à chave de índice traz benefícios adicionais (por exemplo, para order by
ou porque pode restringir o intervalo de leitura do índice), adicione-o à chave.
Você pode ler uma discussão mais longa sobre isso aqui:
https://use-the-index-luke.com/blog/2019-04/include-columns-in-btree-indexes