Acho que estou gastando muito tempo ultimamente examinando listas de índices propostos que foram gerados por um consultor de ajuste de índice ou algum outro processo automatizado.
Naquela época (por volta de 2005), achei as sugestões bastante horríveis, pois pareciam voltadas para uma consulta específica e, na maioria das vezes, eram apenas um índice de cobertura que tinha todas as colunas da tabela, independentemente de essas colunas já serem ou não índices .
Com o passar do tempo, sinto que os consultores de ajuste de índice melhoraram drasticamente, mas ainda tenho uma desconfiança interna e ainda quero gastar tempo revisando cada um deles.
Estou tentando não ser pessimista, mas é difícil quando um fornecedor (Microsoft) sugere adicionar vários índices de cobertura sobrepostos para melhorar o desempenho, especialmente quando estamos pagando pelo espaço de armazenamento. Eu também não quero gastar meu próprio tempo desnecessariamente. Eu preferiria corrigir consultas mal escritas.
Lembre-se de que é apenas um conselheiro... assim como na vida, eles nem sempre estão no caminho certo que você deve seguir. É grátis aconselhar pegar ou sair.
Na maioria das vezes, ele se baseia nos dados do DMV no SQL Server, para que possa até mesmo flutuar no que considera um problema. Eu geralmente os considero como um guia.
Exemplo:
Vejo um conjunto comum de tabelas mostrando índices "sugeridos". Bem, isso me diria que talvez os índices atuais, para essas tabelas, precisem ser revisados em relação à carga atual que está sendo executada. O arquiteto de índice pode mudar ao longo da vida de um aplicativo, os índices criados durante o lançamento da versão 1.0 podem não ser os mesmos quando você atingir a versão 5.0.
Talvez eu use sp_BlitzIndex ou a análise de índice de Jason Strate para examinar a tabela e os índices. Talvez passe e capture os planos de execução para as tabelas host ou extraia-os do cache.
Lembre-se, porém, vale a pena testar qualquer índice que você adicionar a uma tabela, se puder. Se não e você estiver modificando os índices, certifique-se de criar um script dos índices atuais para poder restaurá-los.
Como um consultor que analisa muitos servidores não gerenciados por DBAs, vejo muitos índices DTA na seção "Acumulador de índice: índice NC não utilizado" de sp_BlitzIndex . Eles também estão frequentemente nas seções "Personalidades de Índice Múltiplo: Chaves duplicadas" ou "Personalidades de Índice Múltiplo: Chaves duplicadas limítrofes". Às vezes, esses índices estão sendo usados, mas eles têm muito poucas leituras e muitas gravações.
Em vez de usar o DTA, eu recomendaria usar sp_BlitzIndex, ou um script alternativo de índices ausentes, para localizar os índices ausentes de alto valor para seu banco de dados. Se estiver usando sp_BlitzIndex, considere os índices com um "benefício estimado por dia" de 5 milhões ou mais. Às vezes, até recomendo aqueles com 1 milhão ou mais se os "usos" forem altos.
Provavelmente não para o DTA, mas quase definitivamente sim para os detalhes de índice ausentes armazenados nos planos de execução.
Eu vejo consultas de lixo ineficientes arrastando servidores o dia todo. Costumo passar listas de índices ausentes junto com planos de execução apenas para ouvir os fornecedores hesitarem. "Não podemos simplesmente aplicar qualquer coisa!"
E assim eles não aplicam nada, não importa quão forte seja a evidência. Teste e perfile e prove - eles não se importam.
Os índices não precisam ser criados à mão e geralmente não é suficiente que você tenha meio índice aqui e meio índice ali - se isso causar loops aninhados ou pesquisas de chave repetidamente em tabelas grandes, isso pode causar problemas.
Há bons motivos para os avisos de índice ausente serem acionados. Obviamente, não vale a pena criar TODOS eles em TUDO e alguns podem não ter um grande impacto benéfico (ao invés disso, ter um impacto benéfico, mas insignificante).
Mas, na maioria das vezes, os principais, conforme analisados por CPU, IO e contagem, acabam sendo benéficos. É mais provável que você tenha um plano de execução ruim com índices ruins do que tropeçar magicamente em um plano de execução de trabalho melhor com índices ruins.
Não é ciência de dados.