Discussion :

[nicocolt]

Bonjour,

Je dispose d'une requête SELECT assez lourde avec plusieurs jointures internes et quelques jointures externes
Mes jointures internes sont faites avec un =
Mes jointures externes sont faites avec un (+)

Je me posais la question de savoir si avec des JOIN, cela ne serait pas plus rapide, mais dans tous les tutos que j'ai pu voir les jointures se font dans la clause FROM et non pas WHERE, et là j'ai un peu de mal à comprendre.

Premièrement : Les JOIN peuvent-ils accélérer le traitement de la requête ?
Deuxièmement : Comment les écrires dans la requête ?

Cordialement,
Nico

[pifor]

Je me posais la question de savoir si avec des JOIN, cela ne serait pas plus rapide,

Pour Oracle, utiliser le mot clé JOIN ou le = dans la clause WHERE ne change rien (JOIN est un standard SQL, c'est tout).

Mais dans tous les tutos que j'ai pu voir les jointures se font dans la clause FROM et non pas WHERE, et là j'ai un peu de mal à comprendre.

C'est simplement parce qu'ils utilisent la syntaxe du SQL standard.

Les JOIN peuvent-ils accélérer le traitement de la requête ?

Je ne crois pas.

Comment les écrires dans la requête ?

Comme vous voulez ...

[orafrance]

Pour Oracle, utiliser le mot clé JOIN ou le = dans la clause WHERE ne change rien (JOIN est un standard SQL, c'est tout).

Tu as déjà vérifier ? Parce que j'ai le sentiment que pour les grosses requêtes ça permet à Oracle de moins permuter pour trouver le bon explain plan et donc parser plus rapidement... du moins, ça me semblerait logique

[Médiat]

Tu as déjà vérifier ? Parce que j'ai le sentiment que pour les grosses requêtes ça permet à Oracle de moins permuter pour trouver le bon explain plan et donc parser plus rapidement... du moins, ça me semblerait logique

J'ai migré une application d'une v7 à la v9i avec des jointures entre une tables > 10 000 000 lignes avec une table >1 000 000 lignes ; ayant lu sur dvp que le moteur de base de données ferait un produit cartésien avec l'ancienne syntaxe de la jointure, j'étais très inquiet quant à la quantité de travail à faire pour changer toutes les requêtes, mais lors des tests je n'ai noté aucune différence de performance (au niveau humain, pas à la ms) entre l'ancienne syntaxe et la nouvelle (que je privilégie, néanmoins, ne serait-ce que pour la lisibilité, et le futur (surtout pour les jointures externes)).

[orafrance]

OK merci pour l'info

En fait, c'est plus la complexité de la requête que la volumétrie qui importe pendant la phase de parsing, mais le retour est intéressant

[pifor]

Fred, non je n'ai pas personnellement vérifié mais si Tom Kyte le dit, c'est très probablement vrai. Voir

http://asktom.oracle.com/pls/ask/f?p...13430766143199

D'ailleurs Tom Kyte semble nettement contre l'utilisation du "JOIN naturel"
(évitons les jeux de mots facile ? )

[Mihaela]

Les plan d'exécution de requetes ecrites avec INNER JOIN et avec = sont parfaitement les mêmes.
Exemple pour l'utilisateur SCOTT/TIGER :

Code :

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

1
2
3
4
5
6
7
8
9
 
select distinct e1.ename, e1.empno
from emp e1, emp e2
where e1.empno= e2.mgr;
 
select distinct e1.ename, e1.empno
from emp e1
inner join emp e2
on e1.empno= e2.mgr;

produisent le même plan de requête et le même temps d'exécution :

Code :

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

1
2
3
4
5
6
7
0 	  	SELECT STATEMENT Optimizer=ALL_ROWS (Cost=7 Card=13 Bytes=14 3) 
1 	0 	    SORT (UNIQUE) (Cost=7 Card=13 Bytes=143) 
2 	1 	        MERGE JOIN (Cost=6 Card=13 Bytes =143) 
3 	2 	            TABLE ACCESS (BY I NDEX ROWID) OF 'EMP' (TABLE) (Cost=2 Card=14 Bytes=112) 
4 	3 	                INDE X (FULL SCAN) OF 'PK_EMP' (INDEX (UNIQUE)) (Cost=1 Card=14) 
5 	2 	            SORT (JOIN) (Cost= 4 Card=13 Bytes=39) 
6 	5 	                TABLE ACCESS (FULL) OF 'EMP' (TABLE) (Cost=3 Card=13 Bytes=39)

De même les deux requetes de jointure externe à gauche :

Code :

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

1
2
3
4
5
6
7
8
 
 select distinct e1.ename, e1.empno
 from emp e1, emp e2
 where e1.empno= e2.mgr(+);
 
 select distinct e1.ename, e1.empno
 from emp e1
 left join emp e2 on  e1.empno= e2.mgr;

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=ALL_ROWS (Cost=27 Card=14 Bytes=1
          96)
 
   1    0   SORT (UNIQUE) (Cost=27 Card=14 Bytes=196)
   2    1     MERGE JOIN (OUTER) (Cost=26 Card=14 Bytes=196)
   3    2       TABLE ACCESS (BY INDEX ROWID) OF 'EMP' (TABLE) (Cost=3 Card=14 Bytes=140)
 
   4    3         INDEX (FULL SCAN) OF 'PK_EMP' (INDEX (UNIQUE)) (Cost=2 Card=14)
 
   5    2       SORT (JOIN) (Cost=23 Card=13 Bytes=52)
   6    5         TABLE ACCESS (FULL) OF 'EMP' (TABLE) (Cost=22 Card=13 Bytes=52)

[chrifo]

Oui mais pour rejoindre la remarque de Fred_D, a-t-on moyen de mesurer le temps nécessaire pour trouver le plan d'exécution ?
L'intérêt me semble limité mais c'est intéressant ...

[Mihaela]

Ce que je voulais dire c'était que Oracle traduit exactement de la même façon le INNER JOIN et le = (i.e. lors de la phase de parsing on traduit les deux par un même opérateur). Ensuite pour le résoudre, Oracle fait sa sauce et donc dans les deux écritures il exécute le même plan et prend le même temps pour faire.

[orafrance]

Oui mais pour rejoindre la remarque de Fred_D, a-t-on moyen de mesurer le temps nécessaire pour trouver le plan d'exécution ?

oui... dans la trace tu t'intéresses au temps du parsing

pifor : c'est quoi une jointure "naturel"... c'est les = ?

[orafrance]

il exécute le même plan et prend le même temps pour faire.

hop hop hop... pas de conclusion attive. C'est pas parce qu'il trouve le même plan (ce qui est heureux quand même ) qu'il a du faire le même nombre de permutations pour le trouver... et donc qu'il a mis le même temps

[Médiat]

pifor : c'est quoi une jointure "naturel"... c'est les = ?

NATURAL JOIN = égalité de toutes les colonnes de même nom, donc inutile de les nommer

[orafrance]

ha oui... il préconise d'indiquer la jointure même si c'est inutile c'est ça ?

[pifor]

Je crois que la jointure naturelle, c'est lorsqu'on ne définit pas les colonnes dans la jointure et que le SGBD choisit lui-même les colonnes qui ont les mêmes noms dans les tables pour réaliser la jointure.

Pas si "naturel" que ça ...