Índices ausentes no SQL Server: impacto e como detectar

O SQL Server registra automaticamente, via Missing Index Feature, quais índices teriam ajudado queries que já rodaram desde o último restart. Não é preciso adivinhar — o dado já existe. O problema é que essa sugestão é ingênua: não considera o custo de manter o índice em escritas, nem sobreposição com índices que já existem.

Onde ver o que falta

SELECT TOP 15
  d.statement AS tabela,
  d.equality_columns, d.inequality_columns, d.included_columns,
  s.avg_user_impact, s.user_seeks + s.user_scans AS uso_estimado
FROM sys.dm_db_missing_index_details d
JOIN sys.dm_db_missing_index_groups g ON g.index_handle = d.index_handle
JOIN sys.dm_db_missing_index_group_stats s ON s.group_handle = g.index_group_handle
ORDER BY s.avg_user_impact * (s.user_seeks + s.user_scans) DESC;

avg_user_impact é uma estimativa percentual de melhoria, não um número absoluto — e é zerado a cada restart do serviço, então essa lista só reflete o que rodou desde então.

Por que não criar tudo que aparece

• Cada índice novo tem custo de manutenção em todo INSERT/UPDATE/DELETE na tabela — tabela com muita escrita não aguenta índice pra cada query.
• A sugestão não sabe se já existe um índice quase igual — dois índices 90% sobrepostos custam manutenção dupla pra ganho marginal.
• avg_user_impact alto numa query que roda uma vez por mês pesa menos que impact médio numa query que roda a cada segundo.

Como priorizar

Multiplicar avg_user_impact pelo uso estimado (seeks + scans) dá uma ordem melhor do que olhar impact isolado — é a mesma lógica de priorizar por impacto agregado, não por porcentagem de melhoria numa query isolada.

O Query Intelligence do codeDB já cruza esse relatório com o custo real de manutenção e o volume de uso, e entrega o DDL do índice priorizado — sem exigir que alguém decida manualmente qual das 40 sugestões vale a pena.