Discussion :

[zoom61]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

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

[jmguiche]

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

http://jpg.developpez.com/oracle/tuning/

[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

[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.

[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

[mnitu]

...

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[laurentschneider]

bon point

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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'

[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.