Ordre d'execution des tables

Version imprimable

21/02/2009, 21h30
zoom61

Ordre d'execution des tables

Salut,

Ma question peut paraître "bête", mais quand on exécute un SELECT avec plusieurs tables, y-a-t-il un ordre de passage des tables en fonction du FROM ?
Exemple :

Code:

SELECT ... FROM (table1 INNER JOIN table2 ON ....) INNER JOIN table3...

La table1 est-elle balayée en 1er, et la table2 en 2nd, etc...

:?
22/02/2009, 13h59
jmguiche

Non, c'est pas comme ça que ça marche.

http://jpg.developpez.com/oracle/tuning/
24/02/2009, 12h10
laurentschneider

en fait, ça dépend de plusieurs paramètres.

Si tu utilises le Rule-Based-Optimizer, et qu'il n'y a pas d'index sur tes tables, Oracle aura tendance de lire de gauche à droite.

Dans ton exemple, tu utilises des parenthèses, donc la jointure entre t1 et t2 sera (probablement) effectuée avant t3. Quoi que Oracle pourrait considérer les parenthèses comme inutiles et joindre différement.

Il existe deux HINTs qui sont parfois utilisé LEADING (10g) et ORDERED. Ces HINTS conseille à Oracle d'utiliser les tables dans l'ordre spécifié.

Au fait, pourquoi tu poses la question? L'ordre n'a aucune importance sur le résultat et la performance, c'est Oracle qui s'en charge :roll:
24/02/2009, 12h59
zoom61

Salut,

J'ai créé deux vues qui sont relativement similaires. Et quand je récupère ces vues dans Access, le temps de traitement de l'une et bien supérieur à l'autre, donc je me demandais s'il y avait une relation entre la position des tables dans le from, car c'est à peut prêt la seule chose qui change entre les deux vues...
Je cherche des solutions, donc je suis ouvert à toutes remarques.

:?
24/02/2009, 13h34
laurentschneider

il est très peu probable que ce soit dû à l'ordre des tables, par contre, le lien posté par jm peut t'aider

Citation:

Envoyé par laurentschneider

...

Si tu utilises le Rule-Based-Optimizer, et qu'il n'y a pas d'index sur tes tables, Oracle aura tendance de lire de gauche à droite.
...

Salut Laurent,
Je me rappelle à avoir lu quelque parte que c’était plutôt de droite à gauche.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
 
SQL> set autotrace traceonly explain
SQL> SELECT /*+ RULE*/* FROM e, d where e.deptno = d.deptno;
 
Plan d'exécution
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=HINT: RULE
   1    0   MERGE JOIN
   2    1     SORT (JOIN)
   3    2       TABLE ACCESS (FULL) OF 'D'
   4    1     SORT (JOIN)
   5    4       TABLE ACCESS (FULL) OF 'E'
 
 
 
SQL> SELECT /*+ RULE*/* FROM d, e where e.deptno = d.deptno;
 
Plan d'exécution
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=HINT: RULE
   1    0   MERGE JOIN
   2    1     SORT (JOIN)
   3    2       TABLE ACCESS (FULL) OF 'E'
   4    1     SORT (JOIN)
   5    4       TABLE ACCESS (FULL) OF 'D'

Mais je ne pense pas que ça a vraiment une importance de nos jours.

bon point :king:

Pour lire de gauche à droite, on peut donc ajouter ORDERED, ce que je recommende de ne PAS faire

Code:

1
2
3
4
5
create table lsc_t1(x number);
create table lsc_t2(x number);
create table lsc_t3(x number);
create table lsc_t4(x number);
alter session set hash_join_enabled=false;

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
select /*+RULE ordered */ * 
from lsc_t1 join lsc_t2 using (x) join lsc_t3 using (x)join lsc_t4 using (x);
Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=HINT: RULE (Cost=28 Card=82 Bytes=4264)
   1    0   MERGE JOIN (Cost=28 Card=82 Bytes=4264)
   2    1     MERGE JOIN (Cost=21 Card=82 Bytes=3198)
   3    2       MERGE JOIN (Cost=14 Card=82 Bytes=2132)
   4    3         SORT (JOIN) (Cost=7 Card=82 Bytes=1066)
   5    4           TABLE ACCESS (FULL) OF 'LSC_T1' (Cost=2 Card=82 Bytes=1066)
   6    3         SORT (JOIN) (Cost=7 Card=82 Bytes=1066)
   7    6           TABLE ACCESS (FULL) OF 'LSC_T2' (Cost=2 Card=82 Bytes=1066)
   8    2       SORT (JOIN) (Cost=7 Card=82 Bytes=1066)
   9    8         TABLE ACCESS (FULL) OF 'LSC_T3' (Cost=2 Card=82 Bytes=1066)
  10    1     SORT (JOIN) (Cost=7 Card=82 Bytes=1066)
  11   10       TABLE ACCESS (FULL) OF 'LSC_T4' (Cost=2 Card=82 Bytes=1066)

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
select /*+RULE */ * 
from lsc_t1 join lsc_t2 using (x) join lsc_t3 using (x)join lsc_t4 using (x);
Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=HINT: RULE
   1    0   MERGE JOIN
   2    1     MERGE JOIN
   3    2       MERGE JOIN
   4    3         SORT (JOIN)
   5    4           TABLE ACCESS (FULL) OF 'LSC_T4'
   6    3         SORT (JOIN)
   7    6           TABLE ACCESS (FULL) OF 'LSC_T3'
   8    2       SORT (JOIN)
   9    8         TABLE ACCESS (FULL) OF 'LSC_T2'
  10    1     SORT (JOIN)
  11   10       TABLE ACCESS (FULL) OF 'LSC_T1'

25/02/2009, 15h27
mnitu

Il y a quelque chose que je trouve très sympa dans ton exemple : le Hint Ordered est plus fort que RULE parce que la première requête a été traitée quand même par le Cost Based Optimizer.