Jointure avec JOIN

Version imprimable

10/07/2006, 19h46
nicocolt

Jointure avec JOIN

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
10/07/2006, 19h57
pifor

Citation:

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

Citation:

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.

Citation:

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

Je ne crois pas.

Citation:

Comment les écrires dans la requête ?

Comme vous voulez ...
11/07/2006, 09h09
orafrance

Citation:

Envoyé par pifor

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 ;)
11/07/2006, 09h23
Médiat

Citation:

Envoyé par Fred_D

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)).
11/07/2006, 09h41
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 :)
11/07/2006, 14h19
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 ? :D)

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:

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:

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:

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:

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)

12/07/2006, 14h29
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 ...
12/07/2006, 14h40
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.
12/07/2006, 14h43
orafrance

Citation:

Envoyé par 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 ?

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

pifor : c'est quoi une jointure "naturel"... c'est les = ?
12/07/2006, 14h44
orafrance

Citation:

Envoyé par Mihaela

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 :D) qu'il a du faire le même nombre de permutations pour le trouver... et donc qu'il a mis le même temps ;)
12/07/2006, 14h46
Médiat

Citation:

Envoyé par Fred_D

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
12/07/2006, 14h48
orafrance

ha oui... il préconise d'indiquer la jointure même si c'est inutile c'est ça ? :ange:
12/07/2006, 14h48
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 ...