L'ordre d'exécution des conditions dans SQL clause 'where'

Êtes-vous sûr vous "n'ont pas le pouvoir" pour voir un plan d'exécution? Que penser de l'utilisation AUTOTRACE?

SQL> set autotrace on
SQL> select * from emp
2  join dept on dept.deptno = emp.deptno
3  where emp.ename like 'K%'
4  and dept.loc like 'l%'
5  /
no rows selected
Execution Plan
----------------------------------------------------------
----------------------------------------------------------------------------------
| Id  | Operation                    | Name         | Rows  | Bytes | Cost (%CPU)|
----------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |              |     1 |    62 |     4   (0)|
|   1 |  NESTED LOOPS                |              |     1 |    62 |     4   (0)|
|*  2 |   TABLE ACCESS FULL          | EMP          |     1 |    42 |     3   (0)|
|*  3 |   TABLE ACCESS BY INDEX ROWID| DEPT         |     1 |    20 |     1   (0)|
|*  4 |    INDEX UNIQUE SCAN         | SYS_C0042912 |     1 |       |     0   (0)|
----------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - filter("EMP"."ENAME" LIKE 'K%' AND "EMP"."DEPTNO" IS NOT NULL)
3 - filter("DEPT"."LOC" LIKE 'l%')
4 - access("DEPT"."DEPTNO"="EMP"."DEPTNO")

Comme vous pouvez le voir, qui donne beaucoup de détails sur la façon dont la requête sera exécutée. Il me dit que:

• la condition "emp.ename comme 'K%'" sera appliqué en premier lieu sur l'analyse complète de l'EMP
• puis la correspondance DEPT dossiers seront sélectionnés par le biais de l'index sur le département.deptno (via les BOUCLES IMBRIQUÉES méthode)
• enfin le filtre "dept.loc comme " l% sera appliquée.

Ce décret d'application n'a rien à voir avec la façon dont les prédicats sont classés dans la clause where, comme on peut le montrer avec cette re-commandé requête:

SQL> select * from emp
2  join dept on dept.deptno = emp.deptno
3  where dept.loc like 'l%'
4  and emp.ename like 'K%';
no rows selected
Execution Plan
----------------------------------------------------------
----------------------------------------------------------------------------------
| Id  | Operation                    | Name         | Rows  | Bytes | Cost (%CPU)|
----------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |              |     1 |    62 |     4   (0)|
|   1 |  NESTED LOOPS                |              |     1 |    62 |     4   (0)|
|*  2 |   TABLE ACCESS FULL          | EMP          |     1 |    42 |     3   (0)|
|*  3 |   TABLE ACCESS BY INDEX ROWID| DEPT         |     1 |    20 |     1   (0)|
|*  4 |    INDEX UNIQUE SCAN         | SYS_C0042912 |     1 |       |     0   (0)|
----------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - filter("EMP"."ENAME" LIKE 'K%' AND "EMP"."DEPTNO" IS NOT NULL)
3 - filter("DEPT"."LOC" LIKE 'l%')
4 - access("DEPT"."DEPTNO"="EMP"."DEPTNO")

OriginalL'auteur Tony Andrews

Comme il a été dit, en regardant le plan d'exécution sera de vous donner quelques informations. Toutefois, à moins d'utiliser le plan de stabilité de la fonction, vous ne pouvez pas compter sur le plan d'exécution restant toujours le même.

Dans le cas de la requête que vous avez posté, il ne ressemble pas à l'ordre de l'évaluation va changer la logique de toute façon, donc je suppose que ce que vous pensez est l'efficacité. Il est assez probable que l'Oracle optimiseur de choisir un plan qui est efficace.

Il y a des trucs que vous pouvez faire pour encourager une commande particulière si vous voulez comparer les performances avec la base de la requête. Dire par exemple que vous vouliez le timestamp condition d'être exécuté en premier. Vous pouvez faire ceci:

WITH subset AS
( SELECT /*+ materialize */
FROM my_table
WHERE CURRENT_TIMESTAMP - 1 < x.CREATION_TIMESTAMP
)
SELECT *
FROM subset
WHERE 
d.attribute3 = 'abcd*'  
AND x.STATUS != 'P' 
AND x.STATUS != 'J' 
AND x.STATUS != 'X' 
AND x.STATUS != 'S' 
AND x.STATUS != 'D'

Le "matérialiser" astuce devrait provoquer l'optimiseur d'exécuter la ligne de requête d'abord, puis de numériser l'ensemble des résultats pour les autres conditions.

Je ne suis pas vous conseiller de le faire comme une habitude. Dans la plupart des cas, le simple fait d'écrire la requête simple conduira à la meilleure exécution des plans.

OriginalL'auteur Dave Costa

Enfin, la base de données relationnelle théorie dit que vous pouvez jamais dépendent de l'ordre d'exécution des clauses de requête, de manière à mieux de ne pas essayer. Comme d'autres l'ont dit, l'optimiseur basé sur les coûts essaie de choisir ce qu'il pense être le mieux, mais même la visualisation expliquer le plan de ne garantie de l'ordre réel qui est utilisé. Expliquer le plan vous indique juste que ce que le CBO recommande, mais c'est toujours pas à 100%.

Peut-être que si vous nous expliquer pourquoi vous essayez de faire cela, certains pourraient faire penser à un plan?

OriginalL'auteur Stew S