Coding Interview Prep · Leçon

Performances de EXISTS et IN

Comprendre quand EXISTS s’arrête dès la première correspondance et dépasse IN, une question fréquente pour les profils expérimentés

Performances de EXISTS et IN est une leçon Coding Interview Prep gratuite sur CoddyKit. Ceci est la leçon 4 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage Coding Interview Prep, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours Coding Interview Prep comprend 4 leçons au total.

Ce que EXISTS vérifie réellement

EXISTS prend une sous-requête et renvoie vrai dès que cette sous-requête produit au moins une ligne. Il ne se soucie pas des valeurs renvoyées — seulement de l'existence d'une ligne.

C'est une vérification booléenne, utilisée dans WHERE.
Elle est presque toujours corrélée : la requête interne fait référence à la ligne externe.

Cette question à elle seule revient dans presque tous les entretiens SQL de niveau intermédiaire à avancé.

Une requête EXISTS élémentaire

Trouvez les clients qui ont passé au moins une commande. La requête interne est corrélée par o.customer_id = c.id ; EXISTS renvoie vrai dès qu'une commande correspondante est trouvée.

Remarquez SELECT 1 — la valeur projetée est sans importance, aussi la plupart des ingénieurs écrivent-ils 1 ou *. Les intervieweurs acceptent l'une ou l'autre ; l'optimiseur ignore la liste de sélection à l'intérieur de EXISTS.

SELECT c.name
FROM customers c
WHERE EXISTS (
  SELECT 1 FROM orders o
  WHERE o.customer_id = c.id
);

Comportement de court-circuit

Le mot-clé essentiel que les intervieweurs veulent entendre est court-circuit. EXISTS cesse de parcourir la requête interne dès qu'il trouve une ligne correspondante. Il n'a jamais besoin de construire ni de dédupliquer la liste complète des correspondances.

À l'inverse, IN matérialise conceptuellement l'ensemble des valeurs de la sous-requête, puis en vérifie l'appartenance. Pour les ensembles internes volumineux ou comportant beaucoup de doublons, cette différence est importante.

La même requête avec IN

Voici l'équivalent avec IN de la requête recherchant les clients ayant des commandes. Le résultat logique est identique, mais le fonctionnement diffère : la sous-requête n'est pas corrélée et produit une liste d'identifiants de clients que la requête externe compare.

Avec les optimiseurs modernes, ces requêtes produisent souvent le même plan — mais sur une table orders volumineuse et comportant beaucoup de doublons, EXISTS peut être plus rapide, car il s'arrête à la première correspondance.

SELECT c.name
FROM customers c
WHERE c.id IN (
  SELECT o.customer_id FROM orders o
);

NOT EXISTS vaut mieux que NOT IN

Voici la conclusion de toute la leçon. NOT EXISTS est la manière sûre d'exprimer une anti-jointure. Contrairement à NOT IN, il n'est pas affecté par les NULL de la requête interne.

Il trouve de manière fiable chaque client sans commande, même si orders.customer_id contient des NULL.

SELECT c.name
FROM customers c
WHERE NOT EXISTS (
  SELECT 1 FROM orders o
  WHERE o.customer_id = c.id
);

Pourquoi NOT EXISTS gère correctement NULL

NOT EXISTS demande seulement la sous-requête corrélée a-t-elle trouvé une ligne correspondante ? — une réponse claire par oui ou non. Un customer_id NULL ne satisfait simplement jamais o.customer_id = c.id ; il ne correspond donc pas et ne fausse pas la logique.

À l'inverse, avec NOT IN, un NULL dans la liste force un UNKNOWN et élimine toutes les lignes. C'est pourquoi les intervieweurs expérimentés préfèrent NOT EXISTS pour les anti-jointures.

Quand IN est réellement préférable

Soyez nuancé — IN n'est pas toujours moins bon. Lorsque la sous-requête renvoie une liste petite, statique et distincte, IN est clair et rapide :

Quelques valeurs littérales ou une petite table de recherche.
Une requête non corrélée que l'optimiseur peut exécuter une fois et mettre en cache.

La requête ci-dessous est tout à fait conforme aux usages ; utiliser EXISTS dans ce cas serait une complication inutile.

SELECT name
FROM products
WHERE category_id IN (
  SELECT id FROM categories WHERE active = true
);

La réponse moderne et honnête

Les optimiseurs évolués (Postgres, les versions récentes de SQL Server et MySQL) réécrivent souvent IN et EXISTS en un même plan de semi-jointure. Pour une simple appartenance positive, les performances sont donc souvent identiques.

Les différences qui comptent encore :

NOT IN contre NOT EXISTS — la correction en présence de NULL (une vraie différence, pas seulement une question de rapidité).
Les tables internes très volumineuses ou dépourvues d'index — EXISTS s'arrête dès la première correspondance.

EXISTS ou JOIN pour vérifier l'existence

Voici une autre formulation souvent soulevée par les intervieweurs : pourquoi ne pas utiliser simplement JOIN ? Une jointure qui ne fait que vérifier l'existence peut multiplier les lignes si le côté droit contient des doublons, ce qui impose un DISTINCT. EXISTS ne duplique jamais la ligne externe.

Pour une simple vérification d'existence, EXISTS est donc plus propre que JOIN ... DISTINCT. Utilisez une jointure lorsque vous avez réellement besoin de colonnes de l'autre table.

SELECT DISTINCT c.name
FROM customers c
JOIN orders o ON o.customer_id = c.id;

Les index font toute la différence

La réponse sur les performances est incomplète sans parler des index. Une vérification EXISTS corrélée effectue la recherche interne pour chaque ligne externe ; un index sur la colonne corrélée — ici orders(customer_id) — est donc ce qui la rend rapide.

Dire "J'indexerais la colonne de jointure sur laquelle porte la corrélation de la sous-requête" transforme une réponse théorique en réponse pratique, ce que les intervieweurs apprécient.

CREATE INDEX idx_orders_customer_id
  ON orders (customer_id);

Phrase clé d'entretien

Dites : "EXISTS est une vérification booléenne corrélée qui s'arrête dès la première ligne correspondante, tandis que IN vérifie l'appartenance à une liste de valeurs. Pour les vérifications positives, les optimiseurs modernes produisent souvent le même plan de semi-jointure. La vraie différence est NOT EXISTS contre NOT IN : NOT EXISTS gère correctement les NULL, je le préfère donc pour les anti-jointures — et je veille à indexer la colonne corrélée."

Vérification rapide

Le point central de la comparaison entre EXISTS et IN.

Récapitulatif

EXISTS et IN, c'est réglé :

EXISTS effectue une vérification booléenne corrélée qui s'arrête dès la première ligne correspondante ; la liste de sélection interne est sans importance.
IN vérifie l'appartenance à un ensemble de valeurs et convient parfaitement aux listes petites, distinctes et non corrélées.
Pour les vérifications positives, les optimiseurs modernes choisissent souvent le même plan de semi-jointure.
Préférez NOT EXISTS à NOT IN pour les anti-jointures — il gère correctement les NULL. Indexez la colonne corrélée.

Cela conclut le cours d'approfondissement des sous-requêtes.

Questions Fréquemment Posées

La leçon « Performances de EXISTS et IN » est-elle gratuite ?

Oui — le texte complet de « Performances de EXISTS et IN » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours Coding Interview Prep, passe à CoddyKit PRO. Le cours Coding Interview Prep comprend 4 leçons au total.

Qu'est-ce que j'apprendrai dans « Performances de EXISTS et IN » ?

Comprendre quand EXISTS s’arrête dès la première correspondance et dépasse IN, une question fréquente pour les profils expérimentés Tu pratiques Coding Interview Prep avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.

Dois-je avoir de l'expérience pour commencer Coding Interview Prep ?

Aucune expérience préalable n'est requise. Coding Interview Prep sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 4 sur 4.

Combien de temps prend la leçon « Performances de EXISTS et IN » ?

La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.

Peux-tu écrire et exécuter du code dans cette leçon Coding Interview Prep ?

Oui. Chaque leçon Coding Interview Prep inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.

Toutes les leçons de ce cours

Sous-requêtes scalaires dans SELECT et WHERE
Sous-requêtes dans la clause FROM (tables dérivées)
Sous-requêtes IN, ANY et ALL
Performances de EXISTS et IN

← Retour à Coding Interview Prep