Meilleures pratiques pour les index non utilisés

Sur la base de cette requête, si je vois une faible quantité de lectures totales (très proche de 0 ou 0, comme 1 ou 2) et une quantité élevée ou modérée de mises à jour utilisateur (je n'ai pas pu trouver d'insertions ou de suppressions avec cette requête) avec un grand nombre de lignes, je devrais en théorie supprimer l'index.

SELECT DISTINCT
    OBJECT_NAME(s.[object_id]) AS ObjectName
       , p.rows TableRows
       , i.name AS [INDEX NAME]
       , (user_seeks + user_scans + user_lookups) AS TotalReads
       , user_updates UserUpdates
FROM sys.dm_db_index_usage_stats s
    INNER JOIN sys.indexes i ON i.[object_id] = s.[object_id] 
        AND i.index_id = s.index_id 
    INNER JOIN sys.partitions p ON p.object_id = i.object_id
WHERE OBJECTPROPERTY(s.[object_id],'IsUserTable') = 1
       AND s.database_id = DB_ID()
       AND i.name IS NOT NULL
ORDER BY (user_seeks + user_scans + user_lookups) ASC

Je veux ici vérifier l'exactitude de cette hypothèse. Par exemple, un index qui existe depuis plus d'un an mais qui n'a jamais été lu, mais très mis à jour, semble être une mauvaise idée. Y a-t-il un scénario où cette hypothèse n'est pas valide?

Ce DMV conserve uniquement des statistiques depuis le dernier redémarrage de SQL Server; la vue est complètement effacée et tout recommence à zéro.

Plus important encore, les lignes de cette vue pour tout index spécifique sont supprimées lorsque cet index est reconstruit (mais pas lorsqu'il est réorganisé). Si vous effectuez une maintenance d'index régulière, il peut être utile de consulter les journaux de maintenance et de voir si l'un des index que vous envisagez de supprimer peut avoir été reconstruit récemment.

Ainsi, prendre des décisions sur la base de faibles lectures depuis le dernier redémarrage, lorsque le dernier redémarrage peut avoir été pour les mises à jour du mardi du correctif de la semaine dernière ou le service pack d'hier, peut ne pas être judicieux. Ou lorsque vous effectuez une maintenance d'index, depuis la dernière reconstruction. Il peut y avoir un rapport qui n'est exécuté qu'une fois par mois, ou une fois par trimestre, ou une fois par an, et il est géré par une personne importante et impatiente.

De plus, un indice pourrait être là pour quelque chose qui se produira à l'avenir que vous ne connaissez pas - une série de rapports en préparation pour la saison des impôts, disons.

Donc, mon conseil est:

Utilisez le DMV pour identifier les index candidats à supprimer , mais ne prenez pas cette décision dans une bulle - vous devez faire les démarches pour déterminer pourquoi un index pourrait exister avant de le supprimer, même s'il semble qu'il n'est pas actuellement utilisé .

Yup la vue n'a que des statistiques depuis le dernier redémarrage. Pour aider à atténuer la configuration d'un travail qui a exécuté une requête comme celle que vous avez publiée mensuellement le matin avant que notre fenêtre de maintenance ne commence à capturer les informations chaque mois avant le redémarrage du serveur. Cela m'a permis d'aller plus loin et de regarder les tendances au fil du temps. J'ai également eu une deuxième requête qui a couru à la recherche d'index éventuellement manquants.

Une autre chose à considérer est quels autres index sont sur la table. Il peut ne pas être utilisé car il s'agit principalement ou complètement d'un doublon d'un autre index. Oui. Le serveur SQL vous permet de créer deux index différents mais identiques, il est donc possible qu'il soit complètement redondant.

Vous pouvez également voir quel pourrait être le plan de requête pour une requête qui utilisait cet index si cet index était supprimé. Aurait-il un autre index à utiliser ou devrait-il probablement revenir à une analyse complète de la table.

Les index finissent par être autant de l'art que de la science car il est vraiment difficile de tout savoir sur ce qui pourrait être exécuté et il finit par changer fréquemment de toute façon.