Jointures SQL explicites et implicites

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;

contre.

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

En termes de performances, ils sont exactement les mêmes (au moins dans SQL Server).

PS: sachez que la IMPLICIT OUTER JOINsyntaxe est déconseillée depuis SQL Server 2005. (La IMPLICIT INNER JOINsyntaxe utilisée dans la question est toujours prise en charge)

Obsolescence de la syntaxe JOIN "à l'ancienne": une chose partielle

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

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)

table1a 166208 lignes; table2a environ 1000 lignes.

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

La seconde syntaxe a la possibilité indésirable d'une jointure croisée: vous pouvez ajouter des tables à la partie FROM sans la clause WHERE correspondante. Ceci est considéré comme dangereux.

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 n'importe quelle base de données relationnelle.

Je suis d'accord avec grom que vous devez 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 joignent des tables et d'autres restreignent les lignes renvoyées avec la syntaxe de jointure ANSI, vous indiquez clairement quelles conditions sont utilisées pour joindre vos tables et lesquelles sont utilisées pour restreindre le résultats.

En termes de performances, ils sont exactement les mêmes (au moins dans SQL Server), mais sachez qu'ils déconseillent cette syntaxe de jointure et qu'elle n'est pas prise en charge par SQL Server2005 dès le départ.

Je pense que vous pensez aux opérateurs * = et = * déconseillés par rapport à la "jointure externe".

Je viens de tester les deux formats donnés et ils fonctionnent correctement sur une base de données SQL Server 2008. Dans mon cas, ils ont donné des plans d'exécution identiques, mais je ne pouvais pas dire avec certitude que ce serait toujours vrai.

@lomaxx: Juste pour clarifier, je suis assez certain que les deux syntaxes ci-dessus sont prises en charge par SQL Serv 2005. La syntaxe ci-dessous n'est PAS prise en charge cependant

select a.*, b.*  
from table a, table b  
where a.id *= b.id;

Plus précisément, la jointure externe (* =) n'est pas prise en charge.

Sur certaines bases de données (notamment Oracle), l'ordre des jointures peut faire une énorme différence pour les performances des requêtes (s'il y a plus de deux tables). Sur une demande, nous avions littéralement deux ordres de grandeur dans certains cas. L'utilisation de la syntaxe de jointure interne vous permet de contrôler cela - si vous utilisez la bonne syntaxe des indices.

Vous n'avez pas spécifié la base de données que vous utilisez, mais la probabilité suggère SQL Server ou MySQL là où cela ne fait aucune différence réelle.

Comme Leigh Caldwell l'a déclaré, l'optimiseur de requêtes peut produire différents plans de requête en fonction de ce qui ressemble fonctionnellement à la même instruction SQL. Pour plus de lecture à ce sujet, jetez un œil aux deux articles de blog suivants: -

Une publication de l'équipe Oracle Optimizer

Une autre publication du blog "Structured Data"

J'espère que vous trouvez cela intéressant.

En termes de performances, cela ne devrait faire aucune différence. La syntaxe de jointure explicite me semble plus propre car elle définit clairement les relations entre les tables dans la clause from et n'encombre pas la clause where.

Fondamentalement, la différence entre les deux est que l'un est écrit à l'ancienne, tandis que l'autre est écrit à la manière moderne. Personnellement, je préfère le script moderne utilisant les définitions interne, gauche, externe et droite car elles sont plus explicatives et rendent le code plus lisible.

Lorsqu'il s'agit de jointures internes, il n'y a pas non plus de réelle différence de lisibilité, cependant, cela peut devenir compliqué lorsque vous traitez avec des jointures gauche et droite car dans l'ancienne méthode, vous obtiendriez quelque chose comme ceci:

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

Ce qui précède est l'ancienne façon dont une jointure gauche est écrite par opposition à ce qui suit:

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

Comme vous pouvez le voir visuellement, la façon moderne dont le script est écrit rend la requête plus lisible. (Par ailleurs, il en va de même pour les jointures droites et un peu plus compliqué pour les jointures externes).

Pour en revenir à la plaque de la chaudière, cela ne fait aucune différence pour le compilateur SQL comment la requête est écrite car il les gère de la même manière. J'ai vu un mélange des deux dans les bases de données Oracle qui ont eu beaucoup de gens qui y écrivaient, les plus âgés et les plus jeunes. Encore une fois, cela se résume à la lisibilité du script et à l'équipe avec laquelle vous développez.

D'après mon expérience, l'utilisation de la syntaxe de la clause de jointure croisée avec une clause where produit souvent un plan d'exécution endommagé par le cerveau, surtout si vous utilisez un produit Microsoft SQL. La façon dont SQL Server tente d'estimer le nombre de lignes de table, par exemple, est sauvagement horrible. L'utilisation de la syntaxe de jointure interne vous permet de contrôler la façon dont la requête est exécutée. Donc, d'un point de vue pratique, étant donné la nature atavique de la technologie de base de données actuelle, vous devez opter pour la jointure interne.