Quelle est la différence entre NOT EXISTS vs NOT IN vs LEFT JOIN WHERE IS NULL?

Il me semble que vous pouvez faire la même chose dans une requête SQL en utilisant soit NOT EXISTS, NOT IN ou LEFT JOIN WHERE IS NULL. Par exemple:

SELECT a FROM table1 WHERE a NOT IN (SELECT a FROM table2)

SELECT a FROM table1 WHERE NOT EXISTS (SELECT * FROM table2 WHERE table1.a = table2.a)

SELECT a FROM table1 LEFT JOIN table2 ON table1.a = table2.a WHERE table1.a IS NULL

Je ne suis pas sûr que toute la syntaxe soit correcte, mais ce sont les techniques générales que j'ai vues. Pourquoi choisirais-je d'utiliser l'un plutôt que l'autre? Les performances diffèrent-elles ...? Lequel de ceux-ci est le plus rapide / le plus efficace? (Si cela dépend de la mise en œuvre, quand utiliserais-je chacun d'eux?)

• NOT IN vs NOT EXISTS vs LEFT JOIN / IS NULL: SQL Server

• NOT IN vs NOT EXISTS vs LEFT JOIN / IS NULL: PostgreSQL

• NOT IN vs NOT EXISTS vs LEFT JOIN / IS NULL: Oracle

• NOT IN vs NOT EXISTS vs LEFT JOIN / IS NULL: MySQL

En un mot:

NOT INest un peu différent: il ne correspond jamais s'il n'y en a qu'un seul NULLdans la liste.

• En MySQL, NOT EXISTSest un peu moins efficace

• Dans SQL Server, LEFT JOIN / IS NULLest moins efficace

• Dans PostgreSQL, NOT INest moins efficace

• En Oracle, les trois méthodes sont identiques.

Si la base de données est bonne pour optimiser la requête, les deux premiers seront transformés en quelque chose de proche du troisième.

Pour des situations simples comme celles que vous interrogez, il devrait y avoir peu ou pas de différence, car elles seront toutes exécutées en tant que jointures. Dans les requêtes plus complexes, la base de données peut ne pas être en mesure de créer une jointure à partir des requêtes not inet not exists. Dans ce cas, les requêtes seront beaucoup plus lentes. D'un autre côté, une jointure peut également mal fonctionner s'il n'y a pas d'index pouvant être utilisé, donc ce n'est pas parce que vous utilisez une jointure que vous êtes en sécurité. Vous devrez examiner le plan d'exécution de la requête pour savoir s'il peut y avoir des problèmes de performances.

En supposant que vous évitiez les nulls, ce sont tous des moyens d'écrire une anti-jointure aide de SQL standard.

Une omission évidente est l'équivalent en utilisant EXCEPT:

SELECT a FROM table1
EXCEPT
SELECT a FROM table2

Notez que dans Oracle, vous devez utiliser l' MINUSopérateur (sans doute un meilleur nom):

SELECT a FROM table1
MINUS
SELECT a FROM table2

En parlant de syntaxe propriétaire, il peut également y avoir des équivalents non standard qui méritent d'être étudiés en fonction du produit que vous utilisez, par exemple OUTER APPLYdans SQL Server (quelque chose comme):

SELECT t1.a
  FROM table1 t1
       OUTER APPLY 
       (
        SELECT t2.a
          FROM table2 t2
         WHERE t2.a = t1.a
       ) AS dt1
 WHERE dt1.a IS NULL;

Lorsqu'il est nécessaire d'insérer des données dans une table avec une clé primaire multi-champs, considérez qu'il sera beaucoup plus rapide (j'ai essayé dans Access mais je pense dans n'importe quelle base de données) de ne pas vérifier "qu'il n'existe pas d'enregistrements avec de telles valeurs dans la table", - plutôt simplement insérer dans la table, et les enregistrements excédentaires (par la clé) ne seront pas insérés deux fois.

La perspective des performances évite toujours d'utiliser des mots-clés inverses tels que NOT IN, NOT EXISTS, ... Parce que pour vérifier les éléments inverses, le SGBD doit parcourir tous les éléments disponibles et supprimer la sélection inverse.