J'ai récemment découvert un fantastique script gratuit chez BrentOzar Unltd
http://www.brentozar.com/blitzindex/
Cela fait une bonne analyse des index existants, de leur fréquence d'utilisation et de la fréquence à laquelle le moteur de recherche recherche un index qui n'existe pas.
Ses conseils sont généralement bons. Parfois, les idées sont un peu trop suggestives. J'ai généralement fait ce qui suit jusqu'à présent:
- Les index supprimés qui n'ont JAMAIS été lus (ou peut-être moins de 50 fois par mois).
- Ajout des index les plus évidents sur les clés étrangères et les champs que je sais que nous utilisons beaucoup.
Je n'ai pas ajouté tous les index recommandés et je suis revenu une semaine plus tard pour constater qu'ils ne sont plus recommandés, car le moteur de requête utilise plutôt certains des nouveaux index!
En règle générale, vous devriez éviter les index sur:
- Très petites tables (moins de 50 à 200 enregistrements): le moteur de requête est souvent plus rapide s'il analyse la table plutôt que de charger l'index, de le lire, de le traiter, etc.
- Évitez les index sur les colonnes avec une faible cardinalité ( http://en.wikipedia.org/wiki/Cardinality_(SQL_statements) ) sur la première colonne mentionnée. Par exemple, l'indexation d'un champ de genre (M / F) est très peu utile, il est tout aussi pratique de parcourir le tableau et de trouver les ~ 50% qui correspondent. S'il est répertorié après quelque chose de plus spécifique dans l'index (par exemple, [date de naissance, sexe]), c'est mieux - vous pouvez souhaiter que tous les hommes naissent au cours d'une période donnée.
Les index clusterisés sont bons - normalement, ils sont basés sur votre clé primaire. Ils aident le moteur de base de données à mettre les données sur le disque en bon ordre. Il est essentiel de comprendre cela pour les tables les plus grandes, car un bon index clusterisé réduit souvent l'espace occupé par la table.
J'ai réduit certaines tables de 900 Mo à 400 Mo, simplement parce qu'elles étaient auparavant des tas non structurés.
http://msdn.microsoft.com/en-us/library/aa933131(v=sql.80).aspx
Réorganiser / Reconstruire
Vous devriez chercher à vérifier les index fragmentés. Un peu de fragmentation c'est bien, ne soyez pas obsédés! http://technet.microsoft.com/en-us/library/ms189858.aspx Découvrez la différence entre réorganiser et reconstruire!
Revoir régulièrement
Les requêtes changent, les volumes de données changent, de nouvelles fonctionnalités sont ajoutées, les anciennes supprimées. Vous devriez les regarder une fois par mois (ou plus souvent si vous avez de gros volumes) et chercher où vous pouvez aider la base de données!
Combien
Dans une vidéo récente, Brent recommande (en règle générale) de ne pas placer plus de 5 index sur une table avec beaucoup d'écriture (par exemple, une commande), et pas plus de 10 s'il est lu beaucoup plus que d'écritures (par exemple, une table de journalisation pour l'analyse) http: / /www.youtube.com/watch?v=gOsflkQkHjg
Global
Ça dépend!
Votre kilométrage varie selon la base de données. Couvrez l'évident (nom de l'employé, date de la commande, etc.) sur vos tables (actuelles / futures) plus grandes. Surveillez, révisez et ajustez si nécessaire. Cela devrait faire partie de votre liste de contrôle de routine lorsque vous gérez vos bases de données :)
J'espère que cela t'aides!