Comment déterminer si un index est requis ou nécessaire
J'ai exécuté un outil d'indexation automatique sur notre base de données MS SQL (j'ai modifié un script provenant de Microsoft qui examine les tableaux de statistiques d'index - Indexation automatique automatisée ). D'après les statistiques, j'ai maintenant une liste de recommandations pour les index qui doivent être créés.
Edit: Les index décrits ci-dessus prennent des informations du DMV qui vous indiquent ce que le moteur de base de données utiliserait pour les index s'ils étaient disponibles et les les scripts prennent les recommandations Top x (par recherches, impact utilisateur, etc.) et les mettent dans un tableau.
(Modifier ci-dessus partiellement tiré de la réponse de Larry Coleman ci-dessous afin de clarifier ce que font les scripts)
Comme je suis nouveau dans l'administration des bases de données et que j'ai fait une recherche rapide sur le net, je suis réticent à franchir le pas et à ajouter aveuglément les index recommandés. Cependant, n'ayant pas d'expérience dans le domaine, je recherche des conseils pour savoir si les recommandations sont nécessaires ou non.
Dois-je exécuter le Générateur de profils SQL ou est-il préférable d'examiner le code qui interroge les tables? Et avez-vous d'autres conseils?
J'utilise scripts d'analyse d'index de Jason Strate (ancien emplacement) . Ils vous indiquent combien vos index existants sont utilisés ainsi que combien d'index manquants auraient été utilisés. Je n'ajoute généralement pas d'index à moins qu'ils ne représentent plus de 5 ou 10% des requêtes sur une table.
Plus important encore, il s'agit de s'assurer que l'application répond assez rapidement aux utilisateurs.
Mise à jour: Articles de blog d'analyse d'index de Jason Strate pour les nouveaux scripts (Nouvel emplacement)
Double mise à jour: Ces jours-ci, j'utilise sp_BlitzIndex® pour effectuer une analyse d'index.
Il y a quelques concepts et termes qu'il est important de comprendre lorsque l'on traite des index. Les recherches, les analyses et les recherches sont quelques-unes des façons dont les index seront utilisés via des instructions select. La sélectivité des colonnes clés fait partie intégrante de la détermination de l'efficacité d'un indice.
Une recherche se produit lorsque l'Optimiseur de requête SQL Server détermine que la meilleure façon de trouver les données que vous avez demandées consiste à analyser une plage dans un index. Les recherches se produisent généralement lorsqu'une requête est "couverte" par un index, ce qui signifie que les prédicats de recherche sont dans la clé d'index et que les colonnes affichées sont dans la clé ou incluses. Une analyse se produit lorsque l'Optimiseur de requête SQL Server détermine que la meilleure façon de rechercher les données consiste à analyser l'intégralité de l'index, puis à filtrer les résultats. Une recherche se produit généralement lorsqu'un index n'inclut pas toutes les colonnes demandées, que ce soit dans la clé d'index ou dans les colonnes incluses. L'optimiseur de requête utilise ensuite la clé en cluster (par rapport à un index en cluster) ou le RID (par rapport à un segment) pour "rechercher" les autres colonnes demandées.
En règle générale, les opérations de recherche sont plus efficaces que les analyses, en raison de l'interrogation physique d'un ensemble de données plus petit. Il y a des situations où ce n'est pas le cas, comme un très petit ensemble de données initiales, mais qui dépasse la portée de votre question.
Maintenant, vous avez demandé comment déterminer l'efficacité d'un indice et il y a quelques points à garder à l'esprit. Les colonnes de clé d'un index cluster sont appelées une clé de cluster. C'est ainsi que les enregistrements sont rendus uniques dans le contexte d'un index clusterisé. Tous les index non cluster comprendront la clé en cluster par défaut, afin d'effectuer des recherches lorsque cela est nécessaire. Tous les index seront insérés, mis à jour ou supprimés pour chaque instruction DML respective. Cela étant dit, il est préférable d'équilibrer les gains de performances dans les instructions sélectionnées par rapport aux hits de performances dans les instructions d'insertion, de suppression et de mise à jour.
Afin de déterminer l'efficacité d'un index, vous devez déterminer la sélectivité de vos clés d'index. La sélectivité peut être définie comme un pourcentage d'enregistrements distincts par rapport au nombre total d'enregistrements. Si j'ai une table [personne] avec 100 enregistrements au total et que la colonne [prénom] contient 90 valeurs distinctes, nous pouvons dire que la colonne [prénom] est sélective à 90%. Plus la sélectivité est élevée, plus la clé d'index est efficace. En gardant à l'esprit la sélectivité, il est préférable de placer vos colonnes les plus sélectives en premier dans votre clé d'index. En utilisant mon exemple précédent [de personne], que se passerait-il si nous avions une colonne [nom_famille] qui était sélective à 95%? Nous voudrions créer un index avec [last_name], [first_name] comme clé d'index.
Je sais que c'était une réponse un peu longue, mais il y a vraiment beaucoup de choses qui déterminent l'efficacité d'un indice, et beaucoup de choses contre lesquelles vous devez évaluer les gains de performance.
J'ai récemment découvert un fantastique script gratuit des gens de 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, cela devient un peu trop suggestif d'idées. Jusqu'à présent, j'ai généralement fait ce qui suit:
- 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 suis revenu une semaine plus tard pour constater qu'ils ne sont plus recommandés car le moteur de requête utilise à la place certains des autres nouveaux index!
En règle générale, vous devez éviter les index sur:
- Très petites tables (moins de 50 à 200 enregistrements): souvent, le moteur de requête est 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 à 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 voudrez peut-être que tous les hommes naissent dans un laps de temps donné.
Les index clusterisés sont bons - ils sont normalement basés sur votre clé primaire. Ils aident le moteur de base de données à mettre les données sur le disque en bon état. Il est très essentiel de comprendre cela pour les plus grandes tables, car un bon index cluster 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 des tas non structurés au préalable. http://msdn.Microsoft.com/en-us/library/aa933131 (v = sql.80) .aspx
Réorganiser/Reconstruire
Vous devriez chercher à rechercher des index fragmentés. Un peu de fragmentation c'est bien, ne soyez pas obsessionnel! http://technet.Microsoft.com/en-us/library/ms189858.aspx Faites la différence entre réorganiser et reconstruire!
Examiner 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 consulter une fois par mois (ou plus souvent si vous avez des volumes élevés) et chercher où vous pouvez aider la base de données!
Combien
Dans une vidéo récente, Brent recommande (généralement) pas plus de 5 index sur une table avec beaucoup d'écriture (par exemple la table des commandes), et pas plus de 10 si elle est lue beaucoup plus qu'écrite (c'est-à-dire la 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'évidence (nom de famille de l'employé, date de commande, etc.) sur vos (plus grandes) tables (actuelles/futures). Surveillez, révisez et ajustez si nécessaire. Cela devrait faire partie de votre liste de contrôle de routine lors de la gestion de vos bases de données :)
J'espère que cela t'aides!
Normalement, il faut avoir une charge de travail spécifique (requêtes) et tester soigneusement l'impact de chaque nouvel index sur la charge de travail. Ce processus itératif devrait toujours inclure une analyse minutieuse des plans d'exécution, qui révélerait quels indices sont utilisés. Le sujet de l'analyse d'une requête est long, et en commençant par le chapitre MSDN dédié Analyse d'une requête est un bon pari.
Parfois, lorsque la charge de travail est trop complexe ou que la connaissance de la conception de la base de données est sommaire, on utilise Database Engine Tuning Advisor , qui effectue une analyse automatique de votre charge de travail et propose des indices. Les propositions doivent, bien entendu, être soigneusement analysées et leur impact doit être mesuré immédiatement.
Donc, si vous suivez mon idée, ajouter un index et mesurer l'impact est vraiment juste un cas de test A/B : vous exécutez votre charge de travail sans l'index en tant que ligne de base, puis vous l'exécutez avec l'indice, mesurer et comparer avec la ligne de base, puis décider, en fonction des paramètres observés et mesurés, si l'impact est bénéfique. La charge de travail est mieux une suite de tests de bonne qualité, mais elle peut également être une relecture d'une charge de travail capturée, voir Comment: relire un fichier de trace .
Une réponse plus synthétique consiste à regarder le sys.dm_db_index_usage_stats afficher et voir comment les indices sont utilisés, mais il s'agit généralement d'une approche pour effectuer une analyse sur site sur une charge de travail inconnue (c'est-à-dire qu'un consultant appelé pour aider commencerait probablement par cela).
Depuis SQL 2005, SQL Server possède DMV qui vous indiquent ce que le moteur de base de données utiliserait pour les index s'ils étaient disponibles. Les vues peuvent vous indiquer quelles colonnes doivent être des colonnes clés, quelles colonnes doivent être incluses et, surtout, combien de fois l'index aurait été utilisé.
Une bonne approche serait de trier la requête d'index manquants par nombre de recherches et d'envisager d'ajouter d'abord les index supérieurs.
Voir aussi: les documents officiels MS DMV