Sous-requêtes corrélées et non corrélées
Comprenez les sous-requêtes corrélées qui font référence à la ligne externe, leurs caractéristiques de performance et les situations où EXISTS est préférable à IN.
Sous-requêtes corrélées et non corrélées est une leçon SQL Academy gratuite sur CoddyKit. Ceci est la leçon 2 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 SQL Academy, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours SQL Academy comprend 4 leçons au total.
Sous-requêtes non corrélées
Une sous-requête non corrélée ne fait pas référence à la ligne externe. Elle s’exécute une fois et son résultat est réutilisé :
SELECT * FROM users
WHERE id IN (
SELECT user_id FROM orders WHERE status = 'paid'
);Sous-requêtes corrélées
Une sous-requête corrélée fait référence à la ligne externe : en théorie, elle est réexécutée pour chaque ligne externe :
SELECT u.id, u.email
FROM users u
WHERE EXISTS (
SELECT 1 FROM orders o
WHERE o.user_id = u.id
AND o.total > 1000
);Comment distinguer les deux ?
Si le SELECT interne fait référence à une colonne du FROM externe, il est corrélé.
Conséquences sur les performances
Une sous-requête corrélée naïve est en O(extérieur × intérieur). Les planificateurs modernes la réécrivent souvent sous forme de semi-jointure ou de jointure par hachage, mais vous devez tout de même écrire la forme la plus simple lorsque c’est possible.
EXISTS ou IN
Pour rechercher « au moins une correspondance » :
-- IN with non-correlated subquery (often the planner's favourite):
SELECT u.* FROM users u
WHERE u.id IN (SELECT user_id FROM orders);
-- EXISTS with correlated subquery (NULL-safe alternative):
SELECT u.* FROM users u
WHERE EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id);NOT EXISTS est toujours préférable à NOT IN
NOT IN ne fonctionne plus correctement lorsque l’ensemble interne contient NULL. Ce n’est pas le cas de NOT EXISTS. Préférez toujours NOT EXISTS pour l’anti-jointure :
-- BUG-prone:
SELECT u.* FROM users u
WHERE u.id NOT IN (SELECT excluded_id FROM blocklist);
-- Safe:
SELECT u.* FROM users u
WHERE NOT EXISTS (SELECT 1 FROM blocklist b WHERE b.excluded_id = u.id);Sous-requêtes corrélées dans SELECT
Le motif de « recherche pour chaque ligne » :
SELECT u.id, u.email,
(SELECT MAX(created_at) FROM orders o WHERE o.user_id = u.id) AS last_order_at
FROM users u;
-- Often readable, but consider a LEFT JOIN + GROUP BY.Sous-requêtes corrélées dans UPDATE
Récupérez une valeur dérivée pour chaque ligne :
UPDATE products p
SET review_count = (
SELECT COUNT(*) FROM reviews r WHERE r.product_id = p.id
);LATERAL JOIN : un motif corrélé plus clair
Pour « rechercher certaines lignes pour chaque ligne externe », LATERAL est souvent plus clair et plus rapide — ce point est abordé dans la leçon Motifs avancés de JOIN.
Mise en cache des sous-requêtes
PostgreSQL ne met pas par défaut les résultats des sous-requêtes en cache d’une ligne à l’autre. Si le même résultat interne est nécessaire de nombreuses fois, utilisez une CTE.
Indexez la colonne de corrélation
La sous-requête interne filtre sur la clé de la ligne externe. Sans index sur cette clé, vous obtenez un parcours complet pour chaque ligne externe.
-- For the orders example, this is essential:
CREATE INDEX orders_user_id_idx ON orders(user_id);Récapitulatif
Les sous-requêtes corrélées font référence à la ligne externe.
- EXISTS est la forme corrélée classique
- Préférez NOT EXISTS à NOT IN
- Indexez la colonne de corrélation
- LATERAL est une solution plus claire dans de nombreux cas
Vérification rapide
Pourquoi NOT EXISTS est-il plus sûr que NOT IN lorsque l'ensemble interne peut contenir NULL ?
Questions Fréquemment Posées
La leçon « Sous-requêtes corrélées et non corrélées » est-elle gratuite ?
Oui — le texte complet de « Sous-requêtes corrélées et non corrélées » 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 SQL Academy, passe à CoddyKit PRO. Le cours SQL Academy comprend 4 leçons au total.
Qu'est-ce que j'apprendrai dans « Sous-requêtes corrélées et non corrélées » ?
Comprenez les sous-requêtes corrélées qui font référence à la ligne externe, leurs caractéristiques de performance et les situations où EXISTS est préférable à IN. Tu pratiques SQL Academy 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 SQL Academy ?
Aucune expérience préalable n'est requise. SQL Academy 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 2 sur 4.
Combien de temps prend la leçon « Sous-requêtes corrélées et non corrélées » ?
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 SQL Academy ?
Oui. Chaque leçon SQL Academy 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, de lignes et de tables
- Sous-requêtes corrélées et non corrélées
- Expressions de table communes (WITH)
- CTE récursives pour les hiérarchies