Início / dba / Perguntas / 33596
Accepted
Barguast
Asked: 2013-01-27 03:03:42 +0800 CST

Indexar colunas incluídas

  • 772

Depois de executar uma consulta bastante pesada, o plano de execução me deu uma sugestão de índice ausente que era da forma:

(Timestamp) INCLUDE (CustomerID, EventID, ID, EmployeeID)

O que parece ser um índice de cobertura (a coluna INCLUDE são todas chaves primárias (ID) ou chaves estrangeiras). No entanto, minha cláusula WHERE de consultas está filtrando por timestamp, CustomerID e EventID. Não sei por que eles não foram incluídos na parte principal do índice.

Portanto, minha pergunta é: há alguma diferença em usar o índice sugerido acima ou qual é a melhor alternativa;

(Timestamp, CustomerID, EventID) INCLUDE (ID, EmployeeID)

Meu entendimento é que isso ainda permitirá a busca de índice somente de carimbo de data/hora, mas também ajudará ainda mais minha consulta por ter os IDs do cliente e do evento (que são filtrados) na parte principal.

Acho que isso tem algo a ver com a largura da parte 'principal' - FYI, timestamp é um datetime2 (0), CustomerID é um int e EventID é um byte.

Estou testando isso sozinho no momento, mas esta é uma tabela ENORME - mais de 1.000.000.000 de linhas - e está demorando para comparar os índices. Isso, e eu gostaria de aprender mais sobre isso.

Obrigado.

sql-server

2 respostas

  1. Provavelmente Timestampé muito seletivo, possivelmente único. Como tal não faz sentido adicionar outros campos à chave, eles apenas aumentarão o tamanho da chave sem contribuir para a seletividade. Tê-los como colunas INCLUÍDAS permite que sejam adicionados apenas às páginas folha, economizando no tamanho geral do índice.

    select top(1000) count(*) as cnt, Timestamp 
from ...
group by Timestamp
order by cnt desc;

    O que o acima retorna?

    • 5
  2. Best Answer

    Então, minha pergunta é: há alguma diferença em usar o índice sugerido acima ou o que eu acho que é uma alternativa melhor ...

    As sugestões de índice ausente feitas pelo otimizador são oportunistas e relevantes apenas para a consulta específica em questão. O otimizador passa por uma fase de análise de índice, onde pode notar a ausência de um índice de cobertura que não encontrou. Essas sugestões não pretendem substituir uma sessão de DTA representativa de carga de trabalho completa, muito menos um design de índice adequado por um profissional de banco de dados qualificado com base em amplo conhecimento dos dados e consultas críticas.

    As sugestões sempre devem ser revisadas, como você fez, para garantir que um conjunto ideal de índices para todas as consultas seja criado - não um índice de cobertura por consulta, como poderia ser o caso se as sugestões fossem seguidas literalmente.

    Existem naturalmente implicações ao ampliar as chaves de um índice em comparação com o uso de INCLUDEcolunas, algumas das quais foram observadas por outros. Eu pessoalmente prefiro INCLUDEas chaves de agrupamento explicitamente onde elas são úteis. Os índices agrupados podem ser alterados e é raro que a pessoa que executa essa alteração verifique se alguma consulta está contando com o comportamento implícito.

    Alterar colunas de INCLUDEpara chaves também pode afetar os planos de consulta de atualização (forma geral e requisitos de proteção do Dia das Bruxas) e há implicações de registro em que as chaves de um índice também podem mudar.

    Eu provavelmente escolheria modificar a sugestão como você fez, mas teria o cuidado de validar os planos de consulta de atualização (= inserir/atualizar/excluir/mesclar) para a tabela afetada.

    • 5

relate perguntas