EXISTS (SELECT 1…) vs EXISTS (SELECT *…) L'un ou l'autre?

Chaque fois que je dois vérifier l'existence d'une ligne dans une table, j'ai tendance à toujours écrire une condition telle que:

SELECT a, b, c
  FROM a_table
 WHERE EXISTS
       (SELECT *  -- This is what I normally write
          FROM another_table
         WHERE another_table.b = a_table.b
       )

Certaines personnes écrivent comme ceci:

SELECT a, b, c
  FROM a_table
 WHERE EXISTS
       (SELECT 1   --- This nice '1' is what I have seen other people use
          FROM another_table
         WHERE another_table.b = a_table.b
       )

Lorsque la condition est NOT EXISTSremplacée par EXISTS: Dans certains cas, je peux l'écrire avec une LEFT JOINcondition supplémentaire (parfois appelée antijointure ):

SELECT a, b, c
  FROM a_table
       LEFT JOIN another_table ON another_table.b = a_table.b
 WHERE another_table.primary_key IS NULL

J'essaie de l'éviter parce que je pense que le sens est moins clair, en particulier lorsque ce qui vous primary_keymanque n'est pas évident, ou lorsque votre clé primaire ou votre condition de jointure est multi-colonne (et vous pouvez facilement oublier l'une des colonnes). Cependant, vous conservez parfois du code écrit par quelqu'un d'autre ... et il est juste là.

1. Y a-t-il une différence (autre que le style) à utiliser à la SELECT 1place SELECT *?
   Existe-t-il des cas où cela ne se comporte pas de la même manière?

2. Bien que ce que j’ai écrit soit le code SQL (AFAIK) standard: existe-t-il une telle différence pour différentes bases de données / versions antérieures?

3. Y-a-t-il un avantage à écrire explicitement un anti-jointure?
   Les planificateurs / optimistes contemporains le traitent-ils différemment de la NOT EXISTSclause?

Non, il n'y a pas de différence d'efficacité entre (NOT) EXISTS (SELECT 1 ...)et (NOT) EXISTS (SELECT * ...)dans tous les principaux SGBD. J'ai souvent vu (NOT) EXISTS (SELECT NULL ...)être utilisé aussi.

Dans certains cas, vous pouvez même écrire (NOT) EXISTS (SELECT 1/0 ...)et le résultat est le même - sans erreur (division par zéro), ce qui prouve que l'expression n'y est même pas évaluée.

A propos de la LEFT JOIN / IS NULLméthode anti - jointure, une correction: cela équivaut à NOT EXISTS (SELECT ...).

Dans ce cas, NOT EXISTSvsLEFT JOIN / IS NULL, vous pouvez obtenir différents plans d’exécution. Dans MySQL par exemple et surtout dans les versions antérieures (antérieures à la version 5.7), les plans seraient assez similaires mais non identiques. Les optimiseurs d'autres SGBD (SQL Server, Oracle, Postgres, DB2) sont, à ma connaissance, plus ou moins capables de réécrire ces 2 méthodes et d'envisager les mêmes plans pour les deux. Néanmoins, il n’existe pas de telle garantie et lors de l’optimisation, il est bon de vérifier les plans de différentes réécritures équivalentes, dans la mesure où il se peut que chaque optimiseur ne réécrit pas (par exemple, des requêtes complexes, avec de nombreuses jointures et / ou des tables dérivées / les sous-requêtes à l'intérieur de la sous-requête, où les conditions de plusieurs tables, les colonnes composites utilisées dans les conditions de jointure) ou les choix et les plans de l'optimiseur sont affectés différemment par les index, les paramètres disponibles, etc.

Notez également que USINGvous ne pouvez pas utiliser tous les SGBD (SQL Server par exemple). Le plus commun JOIN ... ONfonctionne partout.
Et les colonnes doivent être préfixées avec le nom de la table / alias dans le SELECTpour éviter les erreurs / ambiguïtés lorsque nous avons des jointures.
Je préfère également généralement mettre la colonne jointe dans la IS NULLvérification (bien que la clé PK ou toute colonne non nullable serait OK, cela pourrait être utile pour l'efficacité lorsque le plan LEFT JOINutilise un index non clusterisé):

SELECT a_table.a, a_table.b, a_table.c
  FROM a_table
       LEFT JOIN another_table 
           ON another_table.b = a_table.b
 WHERE another_table.b IS NULL ;

Il existe également une troisième méthode pour les anti-jointures, NOT INmais elle utilise une sémantique (et des résultats!) Différents si la colonne de la table interne est nullable. Il peut être utilisé en excluant les lignes NULL, rendant la requête équivalente aux 2 versions précédentes:

SELECT a, b, c
  FROM a_table
 WHERE a_table.b NOT IN 
       (SELECT another_table.b
          FROM another_table
         WHERE another_table.b IS NOT NULL
       ) ;

Cela donne aussi généralement des plans similaires dans la plupart des SGBD.

Il existe une catégorie de cas où SELECT 1et SELECT *qui ne sont pas interchangeables - plus précisément, l'un sera toujours accepté dans ces cas, tandis que l'autre ne le sera généralement pas.

Je parle de cas où vous devez vérifier l'existence de lignes d'un ensemble groupé . Si table Tcontient des colonnes C1et C2que vous vérifiez l'existence de groupes de lignes correspondant à une condition spécifique, vous pouvez utiliser la SELECT 1méthode suivante:

EXISTS
(
  SELECT
    1
  FROM
    T
  GROUP BY
    C1
  HAVING
    AGG(C2) = SomeValue
)

mais vous ne pouvez pas utiliser SELECT *de la même manière.

C'est simplement un aspect syntaxique. Lorsque les deux options sont acceptées syntaxiquement, vous n'aurez probablement aucune différence en termes de performances ou de résultats renvoyés, comme cela a été expliqué dans l' autre réponse .

Notes complémentaires à la suite des commentaires

Il semble que peu de produits de base de données supportent cette distinction. Des produits tels que SQL Server, Oracle, MySQL et SQLite accepteront volontiers SELECT *la requête ci-dessus sans erreur, ce qui signifie probablement qu'ils traitent un EXISTS SELECTde manière particulière.

PostgreSQL est un SGBDR sur lequel le système SELECT *peut échouer, mais peut toujours fonctionner dans certains cas. En particulier, si vous regroupez par PK, SELECT *tout fonctionnera correctement, sinon le message:

ERREUR: la colonne "T.C2" doit apparaître dans la clause GROUP BY ou être utilisée dans une fonction d'agrégat

Une façon sans doute intéressante de réécrire la EXISTSclause qui aboutit à une requête plus claire et peut-être moins trompeuse, du moins dans SQL Server, serait la suivante:

SELECT a, b, c
  FROM a_table
 WHERE b = ANY
       (
          SELECT b
          FROM another_table
       );

La version anti-semi-jointure de cela ressemblerait à ceci:

SELECT a, b, c
  FROM a_table
 WHERE b <> ALL
       (
          SELECT b
          FROM another_table
       );

Les deux sont généralement optimisés sur le même plan que WHERE EXISTSou WHERE NOT EXISTS, mais l'intention est indéniable, et vous n'avez pas d '"étrange" 1ou *.

Fait intéressant, les problèmes de contrôle nul associés à NOT IN (...)sont problématiques pour <> ALL (...), alors qu'ils NOT EXISTS (...)ne souffrent pas de ce problème. Considérez les deux tables suivantes avec une colonne nullable:

IF OBJECT_ID('tempdb..#t') IS NOT NULL
BEGIN
    DROP TABLE #t;
END;
CREATE TABLE #t 
(
    ID INT NOT NULL IDENTITY(1,1)
    , SomeValue INT NULL
);

IF OBJECT_ID('tempdb..#s') IS NOT NULL
BEGIN
    DROP TABLE #s;
END;
CREATE TABLE #s 
(
    ID INT NOT NULL IDENTITY(1,1)
    , SomeValue INT NULL
);

Nous allons ajouter des données aux deux, avec des lignes qui correspondent et d'autres qui ne le sont pas:

INSERT INTO #t (SomeValue) VALUES (1);
INSERT INTO #t (SomeValue) VALUES (2);
INSERT INTO #t (SomeValue) VALUES (3);
INSERT INTO #t (SomeValue) VALUES (NULL);

SELECT *
FROM #t;

+ -------- + ----------- +
| ID | SomeValue |
+ -------- + ----------- +
| 1 | 1 |
| 2 | 2 |
| 3 | 3 |
| 4 | NULL |
+ -------- + ----------- +

INSERT INTO #s (SomeValue) VALUES (1);
INSERT INTO #s (SomeValue) VALUES (2);
INSERT INTO #s (SomeValue) VALUES (NULL);
INSERT INTO #s (SomeValue) VALUES (4);

SELECT *
FROM #s;

+ -------- + ----------- +
| ID | SomeValue |
+ -------- + ----------- +
| 1 | 1 |
| 2 | 2 |
| 3 | NULL |
| 4 | 4 |
+ -------- + ----------- +

La NOT IN (...)requête:

SELECT *
FROM #t 
WHERE #t.SomeValue NOT IN (
    SELECT #s.SomeValue
    FROM #s 
    );

A le plan suivant:

La requête ne renvoie aucune ligne car les valeurs NULL rendent impossible la confirmation de l'égalité.

Cette requête, avec <> ALL (...)affiche le même plan et ne renvoie aucune ligne:

SELECT *
FROM #t 
WHERE #t.SomeValue <> ALL (
    SELECT #s.SomeValue
    FROM #s 
    );

La variante using NOT EXISTS (...)affiche une forme de plan légèrement différente et renvoie des lignes:

SELECT *
FROM #t 
WHERE NOT EXISTS (
    SELECT 1
    FROM #s 
    WHERE #s.SomeValue = #t.SomeValue
    );

Le plan:

Les résultats de cette requête:

+ -------- + ----------- +
| ID | SomeValue |
+ -------- + ----------- +
| 3 | 3 |
| 4 | NULL |
+ -------- + ----------- +

Cela rend l'utilisation <> ALL (...)aussi sujette à des résultats problématiques que NOT IN (...).

La "preuve" qu'ils sont identiques (en MySQL) est à faire

EXPLAIN EXTENDED
    SELECT EXISTS ( SELECT * ... ) AS x;
SHOW WARNINGS;

puis répétez avec SELECT 1. Dans les deux cas, la sortie "étendue" montre qu'elle a été transformée SELECT 1.

De même, COUNT(*)est transformé en COUNT(0).

Autre chose à noter: des améliorations d’optimisation ont été apportées dans les versions récentes. Il peut être intéressant de comparer EXISTSvs anti-jointures. Votre version peut faire un meilleur travail avec l'un par rapport à l'autre.

Dans certaines bases de données, cette optimisation ne fonctionne pas encore. Comme par exemple dans PostgreSQL La version 9.6 échouera.

SELECT *
FROM ( VALUES (1) ) AS g(x)
WHERE EXISTS (
  SELECT *
  FROM ( VALUES (1),(1) )
    AS t(x)
  WHERE g.x = t.x
  HAVING count(*) > 1
);

Et ça va réussir.

SELECT *
FROM ( VALUES (1) ) AS g(x)
WHERE EXISTS (
  SELECT 1  -- This changed from the first query
  FROM ( VALUES (1),(1) )
    AS t(x)
  WHERE g.x = t.x
  HAVING count(*) > 1
);

C'est un échec parce que ce qui suit échoue, mais cela signifie qu'il y a toujours une différence.

SELECT *
FROM ( VALUES (1),(1) ) AS t(x)
HAVING count(*) > 1;

Vous pouvez trouver plus d'informations sur ce caprice particulier et la violation de la spécification dans la réponse à la question suivante: La spécification SQL requiert-elle un GROUP BY dans EXISTS ()

J'ai toujours utilisé select top 1 'x'(SQL Server)

Théoriquement, select top 1 'x'serait plus efficace que select *, puisque le premier serait complet après avoir sélectionné une constante sur l’existence d’une ligne qualificative, alors que le second sélectionnerait tout.

CEPENDANT, même si cela a très tôt été pertinent, l’optimisation a rendu la différence non pertinente dans probablement tous les principaux RDBS.

IF EXISTS(SELECT TOP(1) 1 FROMest une meilleure habitude à long terme et sur toutes les plateformes simplement parce que vous n’avez même pas besoin de vous inquiéter de la qualité de votre plate-forme / version actuelle; et SQL va de TOP nparamétrable TOP(n). Cela devrait être une compétence unique.