Discussion :

[PNT007]

Bonjour,

Comment choisir la meilleure requête SQL ?
Pour un même résultat, j'ai le choix entre les trois requêtes ci-dessous:

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
 
/* 3 requetes pour le même résultat, laquelle est la meilleure ? */
 
select art.ref1, uom.name
from table1 art, table2 uom
where art.ref1 like 'xxxxxx' and art.class_id=100 and uom.object_id=art.uom_id;
 
select Ref1, (select name from table2 where object_id=uom_id)
from table1
where ref1 like 'xxxxxx' and class_id=100;
 
select art.ref1, uom.name
from table1 art
inner join table2 uom on uom.object_id=art.uom_id
where art.ref1 'xxxxxx' and art.class_id=100;

Laquelle est la meilleure, en terme de performance et de syntaxe ?

Merci pour vos conseils.

[Séb.]

La 2e est une aberration à oublier.

En terme de résultat et vitesse la 1re et la 3e devraient être équivalentes car dans la 1re l'optimiseur comprend que tu ne veux pas faire un produit cartésien (opérateur , ou CROSS JOIN) mais une jointure interne (critère dans le WHERE).

La 3e, avec le INNER JOIN, est plus compréhensible par l'homme et représente mieux ton intention réelle, elle doit donc être privilégiée.

[Waldar]

La 2e est une aberration à oublier.

Pas nécessairement, les sous-requêtes scalaires ont leur utilité.

C'est une forme de contrainte supplémentaire, la sous-requête ne pouvant retourner que zéro ou une ligne.
Supposant que la colonne object_id porte une caractéristique primaire ou unique, cette contrainte est levée de facto.

Typiquement pour ne retourner que quelques lignes sur un ensemble plus important, cette syntaxe peut être plus rapide à l'exécution que la version jointure.
J'insiste sur le peut car il y a beaucoup trop d'inconnues sur un simple fil forum pour être affirmatif.
Imaginez un dataset qui renvoie 20.000 lignes dans un site web mais qui ne veut afficher que 50 lignes par page.

Sur une version ensembliste avec toutes les lignes retournées, la version jointure sera toujours la plus efficace (là je suis affirmatif).

[vanagreg]

Pas nécessairement, les sous-requêtes scalaires ont leur utilité.

Je confirme, il m'est arrivé à plusieurs reprises de convertir des inner joins en requêtes scalaires, et ça a vraiment amélioré les perfs de la requête. A noter qu'il faut un index dans ce cas (sur la PK idéalement).

[al1_24]

En résumé, il n'y a pas de règle absolue.
Il faut tester, comparer les plans d'exécution, réfléchir à l'indexation, ne pas oublier la mise à jour des statistiques...
Et, sur une application critique, s'assurer que les choix effectués à un instant restent valides dans le temps avec l'évolution des volumes.

[SQLpro]

Déjà la requête 3 est fausse :

where art.ref1 'xxxxxx'

Ne veut rien dire. Je suppose que c'est :

Code :

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

where art.ref1 LIKE  'xxxxxx'

Ensuite cela dépend du SGBDR utilisé. Par exemple les requêtes 1 et 3 (rectifiée) seront récrites de la même façon avec un JOIN dans un bon SGBDR (SQL Server, IBM DB2, Oracle, PostGreSQL...). Mais cela nécessite plus de travail que l'écriture directe avec un JOIN...

Ensuite la requête 2 peut être récrite comme la 3 (avec un JOIN) selon les contraintes présente dans les tables (PRIMARY KEY, UNIQUE, FOREIGN KEY...) notamment, sur un très bon SGBDR ((SQL Server, IBM DB2, Oracle...).

Donc, ans connaître la structure des tables ni le SGBDR impossible à dire !

Enfin cela dépend aussi des index créés !

A +

[PNT007]

Bonjour,

Merci pour vos réponses.
J'en conclue qu'il n'y a pas de règle absolue et que seul des tests en situation donne la solution.

[escartefigue]

Oui, il faut tester, sachant qu'une même requête ne donnera pas les mêmes performances sur deux plates-formes distinctes (production et recette par exemple) ni à deux moments différents.
En effet, l'optimiseur s'appuie sur les statistiques pour choisir son chemin d'accès, or celles-ci évoluent avec le contenu des tables et index (distribution des clefs différentes, fragmentation des espaces...)
Ce faisant, valider les performances sur une plate-forme échantillon, comme celle de tests unitaires, est une erreur, car ça ne préjuge en rien des perfs en production.