La sortie d'EXPLAIN PLAN est une sortie de débogage de l'optimiseur de requête d'Oracle. Le COST est la sortie finale de l'optimiseur basé sur les coûts (CBO), dont le but est de sélectionner lequel des nombreux plans possibles doit être utilisé pour exécuter la requête. Le CBO calcule un coût relatif pour chaque plan, puis choisit le plan avec le coût le plus bas.
(Remarque :dans certains cas, le CBO n'a pas assez de temps pour évaluer tous les plans possibles ; dans ces cas, il choisit simplement le plan avec le coût le plus bas trouvé jusqu'à présent)
En général, l'un des plus gros contributeurs à une requête lente est le nombre de lignes lues pour traiter la requête (blocs, pour être plus précis), donc le coût sera basé en partie sur le nombre de lignes, les estimations de l'optimiseur devront être lues.
Par exemple, supposons que vous ayez la requête suivante :
SELECT emp_id FROM employees WHERE months_of_service = 6;
(Les months_of_service la colonne a une contrainte NOT NULL et un index ordinaire dessus.)
L'optimiseur peut choisir ici deux plans de base :
- Plan 1 :Lire toutes les lignes de la table "employés", pour chacune, vérifier si le prédicat est vrai (
months_of_service=6). - Plan 2 :Lire l'index où
months_of_service=6(cela donne un ensemble de ROWID), puis accédez à la table en fonction des ROWID renvoyés.
Imaginons que la table « employés » comporte 1 000 000 (1 million) de lignes. Imaginons en outre que les valeurs de month_of_service vont de 1 à 12 et sont réparties assez uniformément pour une raison quelconque.
Le coût du Plan 1 , qui implique un FULL SCAN, sera le coût de lecture de toutes les lignes de la table des employés, qui est approximativement égal à 1 000 000 ; mais comme Oracle sera souvent capable de lire les blocs à l'aide de lectures multi-blocs, le coût réel sera inférieur (selon la configuration de votre base de données) - par ex. imaginons que le nombre de lectures multi-blocs est de 10 - le coût calculé de l'analyse complète sera de 1 000 000/10 ; Coût global =100 000.
Le coût du Plan 2 , qui implique un INDEX RANGE SCAN et une recherche de table par ROWID, sera le coût de l'analyse de l'index, plus le coût d'accès à la table par ROWID. Je n'entrerai pas dans le détail du coût des balayages de plage d'index, mais imaginons que le coût du balayage de plage d'index soit de 1 par ligne ; nous nous attendons à trouver une correspondance dans 1 cas sur 12, donc le coût de l'analyse de l'index est de 1 000 000 / 12 =83 333 ; plus le coût d'accès à la table (supposons 1 lecture de bloc par accès, nous ne pouvons pas utiliser de lectures multi-blocs ici) =83 333 ; Coût global =166 666.
Comme vous pouvez le voir, le coût du Plan 1 (analyse complète) est MOINS que le coût du Plan 2 (analyse de l'index + accès par rowid) - ce qui signifie que le CBO choisira l'analyse COMPLÈTE.
Si les hypothèses faites ici par l'optimiseur sont vraies, alors en fait le plan 1 sera préférable et beaucoup plus efficace que le plan 2 - ce qui réfute le mythe selon lequel les analyses FULL sont "toujours mauvaises".
Les résultats seraient assez différents si l'objectif de l'optimiseur était FIRST_ROWS(n) au lieu de ALL_ROWS - auquel cas l'optimiseur favoriserait le plan 2 car il retournera souvent les premières lignes plus rapidement, au prix d'être moins efficace pour l'ensemble de la requête .
