Determinando que Índices em uma Tabela Não São Utilizados

Eu estive executando este script para tentar encontrar índices estranhos

select o.name as TableName, i.name as IndexName, p.reserved_page_count * 8.0 / 1024 as     SpaceInMB, s.*
from     sys.dm_db_index_usage_stats s
inner join sys.objects o on s.object_id = o.object_id
inner join sys.indexes i on i.index_id = s.index_id and i.object_id = o.object_id
inner join sys.dm_db_partition_stats p on i.index_id = p.index_id and o.object_id =      p.object_id
where o.name = ‘TableName’

Eu sei que quando last_user_seek / scan / lookup são todos nulos, que nenhum usuário usou o índice desde a última reinicialização. Mas eu estou querendo saber o que system_scans / pesquisas / procura ... são? Porque em uma determinada tabela eu encontrei 5 que não tinham atividade do usuário, mas uma tinha atividade do sistema há 10 dias. Alguém tem alguma idéia sobre quais varreduras / buscas / pesquisas de sistema podem ser? Essas tabelas parecem realmente super indexadas e eu gostaria de cortar a gordura.

Manutenção do índice (reconstrução / reorganização) e atividade do DBCC CHECKDB provavelmente, possivelmente atualizações de estatísticas. Alguma manutenção agendada configurada?

Se não houver acesso do usuário, bin-los. Lembre-se do período de tempo em que você decide que eles não serão mais usados. Existem tarefas de relatórios semanais ou mensais, por exemplo?

Enquanto procura, procure também índices duplicados .

Editar: sobre o link SSC

A partir de uma rápida varredura no tópico, parece que o pessoal do SSC tinha pensamentos semelhantes. No entanto, eles estão adotando uma postura mais cautelosa quanto ao possível uso "ocasional" desses índices, assumindo a posição de que alguém os colocou ali por uma razão, um argumento perfeitamente razoável. O contra-argumento é que, com muita frequência, é exatamente o oposto: alguém os colocou lá porque pensavam que era a coisa certa a fazer, mas por falta de entendimento ou falta de teste, não era.

Trouxe alguns sistemas de volta ao limiar, sem fazer nada além de eliminar índices não utilizados e duplicados. A indexação excessiva pode causar caos.

É o seu sistema, você precisa entender e ponderar os riscos de deixar esses índices no lugar ou descartá-los. Se você decidir prosseguir com a queda, documente o que faz, por que está fazendo, escreva os índices e publique para todas as partes interessadas.

Glenn Berry escreveu ótimos scripts para ajudá-lo a encontrar os índices ausentes. Eu sugiro usar os scripts dele que tiram parte do trabalho de adivinhação da tarefa para você. Esses scripts não estão apenas procurando pesquisas / varreduras / pesquisas nulas ou 0 de usuários, mas também procurando índices que tenham uma grande variação entre a atividade de leitura e a atividade de gravação, possivelmente ainda resultando em melhor desempenho geral ao cair. Eu verificaria os scripts dele - você pode começar neste post .

Eu não estaria preocupado com a atividade do sistema. Isso não é algo que piorará se você remover os índices; na verdade, pode ser uma atividade que só acontece nesse índice porque existe. A principal coisa com a qual você se importa é a atividade de leitura do usuário e a atividade de gravação do usuário, além de equilibrar isso.

Lembre-se de que os índices também fornecem informações úteis ao Query Optimizer, mesmo que não sejam usados. Fiz várias coisas sobre o impacto da exclusividade, por exemplo. Se você remover um índice exclusivo porque não possui buscas ou verificações, ainda poderá afetar adversamente o desempenho.

Além do que todos declararam, os índices em relação às colunas do FK referenciadas podem nunca mostrar buscas ou varreduras, mas são usados ​​nos bastidores.