Explicite vs implicite des jointures SQL

Question

Est-il de l'efficacité de la différence explicite vs implicite inner join?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

Performance sage, ils sont exactement les mêmes (au moins dans SQL Server).

PS:Être conscient que l' IMPLICIT OUTER JOIN la syntaxe est obsolète depuis SQL Server 2005.(Le IMPLICIT INNER JOIN la syntaxe utilisée dans la question est toujours pris en charge)

La dépréciation de "Old Style" Syntaxe de JOINTURE:Seulement Une Partie De La Chose

Answer 2

Personnellement, je préfère la syntaxe de jointure comme sa le rend plus clair que les tables sont jointes et comment ils sont rejoints.Essayez de comparer les plus grandes requêtes SQL où vous en sélectionnant à partir de 8 tables différentes et vous avez beaucoup de filtrage dans les où les.En utilisant la syntaxe de jointure vous séparer les pièces où les tables sont jointes, à la partie où vous filtrez les lignes.

Answer 3

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

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 propos de 1000 lignes.

C'est un cas très simple;il n'est pas par tous les moyens de prouver que l'optimiseur de requête ne peut pas se confondre et de générer des plans différents dans un cas plus compliqué.

Answer 4

La deuxième syntaxe a ou non possibilité d'une jointure croisée:vous pouvez ajouter des tables à PARTIR de la partie sans clause where.Ceci est considéré comme nocif.

Answer 5

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

Je suis d'accord avec grom que vous devez utiliser ANSI syntaxe de jointure.Comme ils l'ont dit, la raison principale est pour plus de clarté.Plutôt que d'avoir une clause where avec beaucoup de prédicats, certaines tables de jointure et d'autres restreindre le nombre de lignes retournées avec la syntaxe de jointure ANSI vous rendre absolument clair quelles conditions sont utilisées pour joindre vos tables et qui sont utilisés pour restreindre les résultats.

Answer 6

@lomaxx:Juste pour préciser, je suis à peu près certain que les deux de syntaxe ci-dessus sont pris en charge par SQL Serv 2005.La syntaxe ci-dessous n'est PAS pris 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 pris en charge.

Answer 7

Performance sage, ils sont exactement les mêmes (au moins dans SQL Server), mais sachez qu'ils sont à déconseiller cette syntaxe de jointure et il n'est pas pris en charge par sql server2005 hors de la boîte.

Je pense que vous êtes la pensée de l'obsolète *= et =* opérateurs vs"outer join".

J'ai juste testé les deux formats de donnée, et qu'ils fonctionnent correctement sur un Serveur SQL server 2008 de la base de données.Dans mon cas, ils ont donné à l'identique des plans d'exécution, mais je ne pouvais pas dire avec confiance que ce serait toujours vrai.

Answer 8

Sur certaines bases de données (notamment Oracle) l'ordre des jointures peuvent faire une énorme différence dans les performances de la requête (si il y a plus de deux tables).Sur une seule application, il nous a littéralement deux ordres de grandeur de différence dans certains cas.À l'aide de la syntaxe inner join vous donne le contrôle sur ce - si vous utilisez les bons conseils de la syntaxe.

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

Answer 9

Que Leigh Caldwell a déclaré, l'optimiseur de requête peut produire différents plans de requête basé sur ce que fonctionnellement ressemble à la même instruction SQL.Pour plus de lecture sur ce, un coup d'oeil à la suite de deux billets de blog:-

Un détachement de l'Optimiseur Oracle de l'Équipe

Un autre détachement de l' "Données Structurées" blog

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

Answer 10

Performance sage, il ne devrait faire aucune différence.De manière explicite de la syntaxe de jointure semble nettoyant pour moi, en tant qu'il définit clairement les relations entre les tables dans la clause from et ne pas encombrer la clause where.

Answer 11

Dans mon expérience, à l'aide de la croix-joignez-vous-avec-un-clause where de la syntaxe produit souvent un cerveau endommagé plan d'exécution, en particulier si vous utilisez un produit Microsoft SQL.La façon dont SQL Server tente d'estimer les nombres de lignes de table, par exemple, est sauvagement horrible.À l'aide de la syntaxe inner join vous donne un certain contrôle sur la façon dont la requête est exécutée.Donc, à partir d'un point de vue pratique, compte tenu de la atavique le caractère de la technologie de base de données, vous devez aller avec la jointure interne.

Answer 12

Fondamentalement, la différence entre les deux est que l'un est écrit dans l'ancien chemin, tandis que l'autre est écrit à la manière moderne.Personnellement, je préfère le moderne script à l'aide de l'intérieur, à gauche, extérieur, de bonnes définitions, parce qu'ils sont plus explicatifs et rend le code plus lisible.

Lorsque vous traitez avec des jointures internes il n'y a pas de réelle différence dans la lisibilité ni, cependant, il peut devenir compliqué lorsque vous traitez avec de gauche et de droite rejoint comme dans l'ancienne méthode, vous obtiendrez quelque chose comme ceci:

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

Le ci-dessus est l'ancienne façon de comment faire une jointure gauche est écrite, par opposition à la suivante:

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

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

Retour à la chaudière de la plaque, il ne fait pas de différence pour le compilateur SQL façon dont la requête est écrite comme il les traite de la même manière.J'ai vu un mélange des deux dans des bases de données Oracle qui ont eu beaucoup de gens de l'écriture en elle, les deux aînés et les plus jeunes.De nouveau, il se résume à la façon lisible le script est et de l'équipe de développement à l'aide.