Performance de IN vs SQL JOIN ?

Question

J’ai un cas où à l’aide d’une jointure ou une IN me donnera les résultats corrects... Qui a généralement de meilleures performances et pourquoi ? Combien faut-il s’appuyer sur quel serveur de base de données est exécutée ? (FYI j’utilise MSSQL)

Answer 1

Généralement parlant, IN et JOIN sont différentes requêtes qui peuvent donner des résultats différents.

SELECT  a.*
FROM    a
JOIN    b
ON      a.col = b.col

n'est pas le même que

SELECT  a.*
FROM    a
WHERE   col IN
        (
        SELECT  col
        FROM    b
        )

sauf b.col est unique.

Cependant, c'est le synonyme de la première requête:

SELECT  a.*
FROM    a
JOIN    (
        SELECT  DISTINCT col
        FROM    b
        )
ON      b.col = a.col

Si la colonne de jointure est - UNIQUE et marqués comme tels, ces deux requêtes donner le même plan, en SQL Server.

Si elle ne l'est pas, alors IN plus rapide que de l' JOIN sur DISTINCT.

Voir cet article dans mon blog pour les détails de performance:

• IN vs JOIN vs EXISTS

Answer 2

Drôle que vous mentionnez que, j’ai fait un blog sur ce sujet.

Voir Oracle vs vs MySQL SQL Server : agrégation vs jointures

Réponse courte : il faut tester et bases de données individuelles varient beaucoup.

Answer 3

C’est plutôt difficile de dire - afin de vraiment savoir qui on travaille mieux, que vous auriez besoin de profil en fait les temps d’exécution.

Comme une règle générale, je pense que si vous avez des indices sur vos colonnes de clés étrangères, et si vous utilisez uniquement (ou principalement) INNER JOIN les conditions, puis la jointure sera légèrement plus rapide.

Mais dès que vous commencez à utiliser OUTER JOIN, ou si vous êtes dépourvu des index de clé étrangères, l’IN peut être plus rapide.

Marc

Answer 4

Ce Fil est assez vieux, mais encore souvent mentionnés. Pour mon goût personnel, c'est un peu incomplet, car il existe une autre manière de poser la base de données avec le mot-clé EXISTE que j'ai trouvé pour être plus rapide, plus souvent que non.

Donc, si vous êtes seulement intéressé par les valeurs du tableau a, vous pouvez utiliser cette requête:

SELECT  a.*
FROM    a
WHERE   EXISTS (
    SELECT  *
    FROM    b
    WHERE   b.col = a.col
    )

La différence peut être énorme si le col n'est pas indexé, parce que la bd n'est pas de trouver tous les enregistrements de b qui ont la même valeur dans le col, il n'a qu'à trouver le tout premier. Si il n'y a pas d'index sur b.col et un grand nombre d'enregistrements dans b une analyse de table pourrait être la conséquence. Avec EN ou une JOINTURE ce serait un full table scan, il EXISTE ce serait seulement une partie de l'analyse de la table (jusqu'à ce que le premier enregistrement correspondant est trouvé).

Si il y a beaucoup de dossiers dans b qui ont le même col valeur vous aurez aussi perdre beaucoup de mémoire pour la lecture de tous ces documents dans un espace temporaire juste pour trouver que votre condition est satisfaite. Avec existe cela peut généralement être évitée.

J'ai souvent constaté EXISTE plus vite, même si il y a un index. Il dépend du système de base de données (l'optimiseur), les données et la dernière pas moins sur le type d'indice qui est utilisé.

Answer 5

Chaque base de données est mise en œuvre, mais vous pouvez probablement le deviner qu'ils sont tous de résoudre des problèmes communs dans le plus ou moins de la même manière. Si vous utilisez MSSQL avoir un regard sur le plan d'exécution est générée. Vous pouvez le faire en activant le générateur de profils et plans d'exécutions. Cela vous donnera une version texte lorsque vous exécutez la commande.

Je ne suis pas certain de la version de MYSQL que vous utilisez, mais vous pouvez obtenir un graphique dans SQL Server 2000 dans l'analyseur de requêtes. Je suis sûr que cette fonctionnalité n'est tapi quelque part dans SQL Server Studio Manager dans les versions ultérieures.

Jetez un oeil à la exeuction plan. Autant que possible, éviter les analyses de la table, à moins bien sûr de votre table est petite dans ce cas, une analyse de la table est plus rapide que l'utilisation d'un index. Lire sur les différentes opérations de jointure que chaque scénario différent produit.