Comment interprétez-vous le plan d'explication d'une requête?

Question

Lorsque vous essayez de comprendre comment une instruction SQL s'exécute, il est parfois recommandé de consulter le plan explicité. Quel est le processus à suivre pour interpréter (donner un sens) d'un plan d'explication? Qu'est-ce qui devrait ressortir, "Oh, ça marche à merveille?" par opposition à "Oh non, ce n'est pas correct."

Answer 1

Je frémis chaque fois que je vois des commentaires indiquant que les analyses complètes de tables sont mauvaises et que l'accès aux index est correct. Les analyses complètes des tables, des plages d'index, des analyses rapides d'index complet, des boucles imbriquées, des jointures de fusion, des 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. pour 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), et bien qu’elle indique souvent un problème de performances, dans le contexte de savoir si c'est un mécanisme efficace pour atteindre les objectifs de la requête. En tant qu’entrepôt de données et expert en 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.

Donc, pour savoir comment lire 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 le Guide de réglage des performances.

Vous pouvez également utiliser Google pour "rétroaction de cardinalité", une technique dans laquelle un plan d'explication peut être utilisé pour comparer les estimations de cardinalité à différentes étapes d'une requête avec les cardinalités réelles expérimentées au cours 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. Comprendre la base de données. Comprendre l'intention de la requête. Évitez les règles de base.

Answer 2

Ce sujet est trop volumineux pour répondre à une question comme celle-ci. Prenez le temps de lire le Guide d'optimisation des performances d'Oracle

Answer 3

Les deux exemples ci-dessous illustrent une analyse FULL et une analyse FAST à l'aide d'un index.

Il est préférable de vous 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 compte à 100%), mais fondamentalement, le coût est fonction du coût du processeur et des E / S, et la cardinalité est le nombre de lignes que Oracle doit analyser. Réduire ces 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: COST, CHOOSE, etc.) et la fréquence à laquelle vous exécutez vos statistiques.

Exemple 1:

SCAN http://docs.google.com/a/shanghainetwork.org/File? id = dd8xj6nh_7fj3cr8dx_b

Exemple 2 d'utilisation des index:

INDEX http://docs.google.com/a/fukuoka-now. com / Fichier? id = dd8xj6nh_9fhsqvxcp_b

Et comme déjà suggéré, faites attention à TABLE SCAN. Vous pouvez généralement les éviter.

Answer 4

Rechercher des éléments tels que les analyses séquentielles peut être quelque peu utile, mais la réalité réside dans les chiffres ... sauf lorsque les chiffres ne sont que des estimations! Ce qui est généralement de loin plus utile que de regarder un plan de requête , c'est de regarder l'exécution réelle . Dans Postgres, c'est la différence entre EXPLAIN et EXPLAIN ANALYZE. EXPLAIN ANALYZE exécute la requête et obtient des informations de minutage réelles pour chaque nœud. Cela vous permet de voir ce qui se produit réellement , au lieu de ce que le planificateur pense que se produira. Vous constaterez souvent que l'analyse séquentielle n'est pas du tout un problème, mais plutôt un autre élément de la requête.

L’autre clé consiste à identifier l’étape la plus coûteuse. De nombreux outils graphiques utiliseront des flèches de tailles différentes pour indiquer le coût des différentes parties du plan. Dans ce cas, il suffit de rechercher les marches avec des flèches fines et une épaisse flèche partant. Si vous n'utilisez pas une 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 cerner les problèmes.

Answer 5

Vraiment pour de tels problèmes, 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 d’expliquer les plans, c’est vraiment la meilleure hypothèse.

Ce serait une bonne idée d'apprendre à utiliser sqlplus et d'expérimenter avec la commande AUTOTRACE. Avec quelques chiffres précis, vous pouvez généralement prendre de meilleures décisions.

Mais vous devriez ASKTOM. Il sait tout à ce sujet:)

Answer 6

Le résultat de l'explication vous indique le temps que chaque étape a pris. La première chose à faire est de trouver les étapes qui ont pris beaucoup de temps et d’en comprendre le sens. Des analyses comme une analyse séquentielle vous indiquent que vous avez besoin de meilleurs index. Il s’agit principalement de rechercher votre base de données et votre expérience.

Answer 7

One "Oh non, ce n'est pas correct" se présente souvent sous la forme d'un scan de table . Les analyses de table n'utilisent pas d'index spéciaux et peuvent contribuer à la purge de toutes les informations utiles dans les caches de mémoire. Dans PostgreSQL, par exemple, vous verrez que cela 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 que vous semblez rechercher.

Answer 8

En gros, vous examinez chaque opération et vous voyez si elle a du sens " compte tenu de vos connaissances sur la manière dont il devrait pouvoir fonctionner.

Par exemple, si vous joignez deux tables, A et B sur leurs colonnes respectives C et D (AC = BD), et que votre plan affiche une analyse d'index en cluster (terme SQL Server - non sûr du terme oracle ) sur la table A, puis une boucle imbriquée rejoindre une série d'index clusterisés cherche sur la table B, vous pourriez penser qu'il y avait un problème. Dans ce scénario, vous pourriez vous attendre à ce que le moteur effectue une paire d'analyses d'index (sur les index des colonnes jointes) suivies d'une jointure de fusion. Une enquête plus approfondie pourrait révéler de mauvaises statistiques, obligeant l'optimiseur à choisir ce modèle de jointure ou un index inexistant.

Answer 9

Examinez le pourcentage de temps passé dans chaque sous-section du plan et déterminez ce que fait le moteur. Par exemple, si vous analysez une table, envisagez de placer un index sur le (s) champ (s) analysé (s)

Answer 10

Je recherche principalement des analyses d'index ou de table. Cela me dit 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 devriez envisager   les signes avant-coureurs et enquêter   eux pour la performance potentielle   problèmes. Chacun d'entre eux sont moins de   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 d'éviter   ceux-ci, mais plus vous pouvez éviter   eux, la performance de requête plus rapide   sera.

Answer 11

Règles empiriques

(vous voudrez probablement aussi lire les détails:

• Docs Oracle
• ASKTOM
• Documents SQL Server
  )

Mauvais

Balayages de plusieurs grandes tables

Bien

Utilisation d'un index unique
L'index inclut tous les champs obligatoires

Victoire la plus courante

Dans environ 90% des problèmes de performances que j'ai rencontrés, la solution la plus simple consiste à scinder une requête comportant plusieurs lots (4 ou plus) de tables en 2 requêtes plus petites et une table temporaire.