Comment interprétez-vous le plan d'explication d'une requête?
Lorsque vous essayez de comprendre comment une instruction SQL s'exécute, il est parfois recommandé de consulter le plan d'explication. Quel processus faut-il suivre pour interpréter (donner un sens) à un plan d'explication? Qu'est-ce qui devrait ressortir comme: "Oh, cela fonctionne à merveille?" contre "Oh non, ce n'est pas juste."
Je frissonne chaque fois que je vois des commentaires selon lesquels les tablescans complètes sont mauvaises et l'accès aux index est bon. Les analyses de table complètes, les analyses d'index, les analyses d'index complet rapides, les boucles imbriquées, les jointures de fusion, les jointures de hachage, etc. sont simplement des mécanismes d'accès qui doivent être compris par l'analyste et combinés à une connaissance de la structure de la base de données et du but d'une requête dans afin de parvenir à une conclusion significative.
Une analyse complète est tout simplement le moyen le plus efficace de lire une grande partie des blocs d'un segment de données (une table ou une (sous) partition de table) et, bien qu'elle puisse souvent indiquer un problème de performances, ce n'est que dans le contexte de savoir s'il s'agit d'un mécanisme efficace pour atteindre les objectifs de la requête. S'exprimant en tant qu'entrepôt de données et type BI, mon indicateur d'avertissement numéro un pour les performances est une méthode d'accès basée sur un index et une boucle imbriquée.
Ainsi, pour le mécanisme de lecture d'un plan d'explication, la documentation Oracle est un bon guide: http://download.Oracle.com/docs/cd/B28359_01/server.111/b28274/ex_plan.htm# PFGRF009
Lisez également attentivement le Guide de réglage des performances.
Ayez également un google pour le "retour de cardinalité", une technique dans laquelle un plan d'explication peut être utilisé pour comparer les estimations de la cardinalité à différentes étapes d'une requête avec les cardinalités réelles rencontrées lors de l'exécution. Wolfgang Breitling est l'auteur de la méthode, je crois.
Donc, en bout de ligne: comprendre les mécanismes d'accès. Comprenez la base de données. Comprenez l'intention de la requête. Évitez les règles de base.
Ce sujet est trop grand pour répondre à une question comme celle-ci. Vous devriez prendre un certain temps pour lire Oracle's Performance Tuning Guide
Les deux exemples ci-dessous montrent un scan COMPLET et un scan RAPIDE utilisant un INDEX.
Il est préférable de se concentrer sur votre coût et votre cardinalité. En regardant les exemples, l'utilisation de l'index réduit le coût d'exécution de la requête.
C'est un peu plus compliqué (et je n'ai pas de poignée à 100%), mais fondamentalement, le coût est une fonction du processeur et IO coût, et la cardinalité est le nombre de lignes Oracle s'attend à analyser. Réduire les deux est une bonne chose.
N'oubliez pas que le coût d'une requête peut être influencé par votre requête et le modèle d'optimiseur Oracle (par exemple: COÛT, CHOISIR, etc.) et la fréquence à laquelle vous exécutez vos statistiques.
Exemple 1:
NUMÉRISER http://docs.google.com/a/shanghainetwork.org/File?id=dd8xj6nh_7fj3cr8dx_b
Exemple 2 utilisant des index:
INDEX http://docs.google.com/a/fukuoka-now.com/File?id=dd8xj6nh_9fhsqvxcp_b
Et comme déjà suggéré, faites attention au SCAN DES TABLEAUX. Vous pouvez généralement les éviter.
Rechercher des choses comme des analyses séquentielles peut être quelque peu utile, mais la réalité est dans les chiffres ... sauf lorsque les chiffres ne sont que des estimations! Ce qui est généralement loin plus utile que de regarder une requête le plan regarde le réel exécution . Dans Postgres, c'est la différence entre EXPLAIN et EXPLAIN ANALYZE. EXPLAIN ANALYZE exécute en fait la requête et obtient des informations de synchronisation réelles pour chaque nœud. Cela vous permet de voir ce qui se passe réellement , au lieu de ce que pense le planificateur qui va se passer. Plusieurs fois, vous constaterez qu'une analyse séquentielle n'est pas du tout un problème, mais plutôt quelque chose d'autre dans la requête.
L'autre clé est d'identifier quelle est l'étape coûteuse réelle. De nombreux outils graphiques utiliseront des flèches de différentes tailles pour indiquer le coût des différentes parties du plan. Dans ce cas, recherchez simplement les étapes avec des flèches fines qui entrent et une flèche épaisse qui part. Si vous n'utilisez pas d'interface graphique, vous devrez regarder les chiffres et chercher où ils deviennent soudainement beaucoup plus grands. Avec un peu de pratique, il devient assez facile de sélectionner les zones à problèmes.
Vraiment pour des problèmes comme ceux-ci, la meilleure chose à faire est ASKTOM . En particulier, sa réponse à cette question contient des liens vers le document Oracle en ligne, où de nombreuses règles de ce type sont expliquées.
Une chose à garder à l'esprit, c'est que les plans d'explication sont vraiment les meilleures suppositions.
Ce serait une bonne idée d'apprendre à utiliser sqlplus et d'expérimenter avec la commande AUTOTRACE. Avec certains chiffres précis, vous pouvez généralement prendre de meilleures décisions.
Mais vous devriez DEMANDER. Il sait tout à ce sujet :)
Le résultat de l'explication vous indique combien de temps chaque étape a pris. La première chose est de trouver les étapes qui ont duré longtemps et de comprendre ce qu'elles signifient. Des choses comme une analyse séquentielle vous indiquent que vous avez besoin de meilleurs index - c'est principalement une question de recherche dans votre base de données et votre expérience particulières.
Un "Oh non, ce n'est pas vrai" est souvent sous la forme d'un scan de table. Les analyses de table n'utilisent aucun index spécial et peuvent contribuer à purger tous les caches mémoire utiles. Dans postgreSQL, par exemple, vous trouverez qu'il ressemble à ceci.
Seq Scan on my_table (cost=0.00..15558.92 rows=620092 width=78)
Parfois, les analyses de table sont idéales, par exemple, en utilisant un index pour interroger les lignes. Cependant, c'est l'un de ces modèles de drapeau rouge que vous semblez rechercher.
Fondamentalement, vous jetez un coup d'œil à chaque opération et voyez si les opérations "ont du sens" compte tenu de votre connaissance de la façon dont elles devraient pouvoir fonctionner.
Par exemple, si vous joignez deux tables, A et B sur leurs colonnes respectives C et D (AC = BD), et votre plan affiche une analyse d'index en cluster (terme SQL Server - pas sûr du terme Oracle) sur la table A, puis une boucle imbriquée jointe à une série de recherches d'index cluster sur la table B, vous pourriez penser qu'il y a eu un problème. Dans ce scénario, vous pouvez vous attendre à ce que le moteur effectue une paire d'analyses d'index (sur les index des colonnes jointes) suivie d'une jointure de fusion. Une enquête plus approfondie peut révéler de mauvaises statistiques, ce qui fait que l'optimiseur choisit ce modèle de jointure ou un index qui n'existe pas réellement.
regardez le pourcentage de temps passé dans chaque sous-section du plan et réfléchissez à ce que fait le moteur. par exemple, s'il analyse une table, envisagez de mettre un index sur le (s) champ (s) qui recherche
Je recherche principalement des scans d'index ou de table. Cela m'indique généralement qu'il me manque un index sur une colonne importante qui se trouve dans l'instruction where ou l'instruction join.
De http://www.sql-server-performance.com/tips/query_execution_plan_analysis_p1.aspx :
Si vous voyez l'un des éléments suivants dans un plan d'exécution, vous devez les considérer comme des signes d'avertissement et rechercher les problèmes de performances potentiels. Chacun d'eux n'est pas idéal du point de vue des performances.
* Index or table scans: May indicate a need for better or additional indexes. * Bookmark Lookups: Consider changing the current clustered index, consider using a covering index, limit the number of columns in the SELECT statement. * Filter: Remove any functions in the WHERE clause, don't include wiews in your Transact-SQL code, may need additional indexes. * Sort: Does the data really need to be sorted? Can an index be used to avoid sorting? Can sorting be done at the client more efficiently?Il n'est pas toujours possible de les éviter, mais plus vous pourrez les éviter, plus les performances des requêtes seront rapides.