Déterminer que les index d'une table ne sont pas utilisés

J'ai exécuté ce script pour essayer de trouver des index superflus

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’

Je sais que lorsque last_user_seek / scan / lookup sont tous nuls, aucun utilisateur n'a utilisé l'index depuis le dernier redémarrage. Mais je me demande ce que sont les analyses système / recherches / recherches…? Parce que sur une certaine table, j'ai trouvé 5 qui n'avaient aucune activité utilisateur, mais l'un avait une activité système il y a 10 jours. Quelqu'un a-t-il une idée de ce que peuvent être les analyses / recherches / recherches système? Ces tableaux semblent vraiment sur-indexés et j'aimerais couper le gras.

Maintenance d'index (reconstruction / réorganisation) et activité DBCC CHECKDB très probablement, éventuellement mises à jour des statistiques. Une maintenance planifiée est-elle configurée?

S'il n'y a pas d'accès utilisateur, supprimez-les. Gardez simplement à l'esprit le laps de temps pendant lequel vous décidez qu'ils ne sont plus utilisés. Existe-t-il des tâches de reporting hebdomadaires ou mensuelles par exemple?

Pendant que vous cherchez, recherchez également des index en double .

Modifier: concernant le lien SSC

D'un rapide survol du fil, on dirait que les gens de SSC avaient des pensées similaires. Ils adoptent cependant une position plus prudente quant à une éventuelle utilisation "occasionnelle" de ces indices, considérant que quelqu'un les a mis là pour une raison, un argument parfaitement raisonnable. Le contre-argument est que trop souvent c'est exactement le contraire, quelqu'un les a mis là parce qu'ils pensaient que c'était la bonne chose à faire, mais par manque de compréhension ou de tests, ce n'était pas le cas.

J'ai ramené quelques systèmes du bord en ne faisant rien d'autre que de supprimer les index inutilisés et dupliqués. Une indexation excessive peut provoquer le chaos.

C'est votre système, vous devez comprendre et peser les risques de laisser ces index en place ou de les supprimer. Si vous décidez d'aller de l'avant avec le drop, documentez ce que vous faites, pourquoi vous le faites, scriptez les index et publiez à toutes les parties intéressées.

Glenn Berry a écrit d'excellents scripts pour vous aider à trouver vos index manquants. Je vous suggère d'utiliser ses scripts qui vous simplifient la tâche. Ces scripts ne recherchent pas seulement des recherches / analyses / recherches nulles ou nulles, mais recherchent également des index qui présentent un grand décalage entre l'activité de lecture et l'activité d'écriture, ce qui peut encore améliorer les performances globales en supprimant. Je vérifierais ses scripts - vous pouvez commencer sur ce post .

Je ne serais pas inquiet de l'activité du système. Ce n'est pas quelque chose qui va empirer si vous supprimez les index, en fait ce pourrait être une activité qui ne se produit que sur cet index car elle existe. La principale chose qui vous intéresse est l'activité de lecture utilisateur et l'activité d'écriture utilisateur et l'équilibrage.

N'oubliez pas que les index fournissent également des informations utiles à l'Optimiseur de requête, même s'ils ne sont pas utilisés. J'ai fait pas mal de choses sur l'impact de l'unicité, par exemple. Si vous supprimez un index unique car il n'a pas de recherches ou d'analyses, vous pouvez toujours nuire aux performances.

En plus de ce que tout le monde a déclaré, les index des colonnes FK référencées peuvent ne jamais afficher les recherches ou les analyses, mais sont utilisés sous les couvertures.