Jointures SQL explicites et implicites

Question

Y a-t-il une différence d'efficacité entre une jointure interne explicite et implicite ? Par exemple :

SELECT * FROM
table a INNER JOIN table b
ON a.id = b.id;

vs.

SELECT a.*, b.*
FROM table a, table b
WHERE a.id = b.id;

Answer 1

Sur le plan des performances, elles sont exactement les mêmes (du moins dans SQL Server).

PS : Sachez que le IMPLICIT OUTER JOIN est dépréciée depuis SQL Server 2005. (La IMPLICIT INNER JOIN la syntaxe utilisée dans la question est toujours supportée)

Dépréciation de la syntaxe JOIN "ancien style" : Une chose partielle seulement

Answer 2

Personnellement, je préfère la syntaxe de jointure car elle indique plus clairement que les tables sont jointes et comment elles sont jointes. Essayez de comparer des requêtes SQL plus importantes où vous sélectionnez 8 tables différentes et où vous avez beaucoup de filtrage dans le where. En utilisant la syntaxe de jointure, vous séparez les parties où les tables sont jointes, de la partie où vous filtrez les lignes.

Answer 3

Sur MySQL 5.1.51, les deux requêtes ont des plans d'exécution identiques :

mysql> explain select * from table1 a inner join table2 b on a.pid = b.pid;
+----+-------------+-------+------+---------------+------+---------+--------------+------+-------+
| id | select_type | table | type | possible_keys | key  | key_len | ref          | rows | Extra |
+----+-------------+-------+------+---------------+------+---------+--------------+------+-------+
|  1 | SIMPLE      | b     | ALL  | PRIMARY       | NULL | NULL    | NULL         |  986 |       |
|  1 | SIMPLE      | a     | ref  | pid           | pid  | 4       | schema.b.pid |   70 |       |
+----+-------------+-------+------+---------------+------+---------+--------------+------+-------+
2 rows in set (0.02 sec)

mysql> explain select * from table1 a, table2 b where a.pid = b.pid;
+----+-------------+-------+------+---------------+------+---------+--------------+------+-------+
| id | select_type | table | type | possible_keys | key  | key_len | ref          | rows | Extra |
+----+-------------+-------+------+---------------+------+---------+--------------+------+-------+
|  1 | SIMPLE      | b     | ALL  | PRIMARY       | NULL | NULL    | NULL         |  986 |       |
|  1 | SIMPLE      | a     | ref  | pid           | pid  | 4       | schema.b.pid |   70 |       |
+----+-------------+-------+------+---------------+------+---------+--------------+------+-------+
2 rows in set (0.00 sec)

table1 a 166208 lignes ; table2 a environ 1000 lignes.

Il s'agit d'un cas très simple ; cela ne prouve en aucun cas que l'optimiseur de requêtes ne s'embrouillerait pas et ne générerait pas des plans différents dans un cas plus compliqué.

Answer 4

La deuxième syntaxe présente la possibilité non désirée d'une jointure croisée : vous pouvez ajouter des tables à la partie FROM sans clause WHERE correspondante. Ceci est considéré comme nuisible.

Answer 5

La première réponse que vous avez donnée utilise ce que l'on appelle la syntaxe de jointure ANSI, l'autre est valide et fonctionnera dans toute base de données relationnelle.

Je suis d'accord avec grom pour dire que vous devriez utiliser la syntaxe de jointure ANSI. Comme ils l'ont dit, la raison principale est la clarté. Plutôt que d'avoir une clause where avec de nombreux prédicats, dont certains rejoignent des tables et d'autres restreignent les lignes renvoyées, avec la syntaxe de jointure ANSI, vous faites apparaître clairement les conditions utilisées pour joindre vos tables et celles utilisées pour restreindre les résultats.