Subs Where Sub Query SQL : Guide complet pour maîtriser les sous-requêtes SQL
Comprendre le concept de sous-requête en SQL
Une sous-requête, ou requête imbriquée, est un outil puissant permettant d’intégrer une requête SQL complète dans une autre. Contrairement à une simple jointure, la sous-requête est évaluée pour chaque ligne de la requête principale ou une fois au début, selon le type de sous-requête. Il offre la flexibilité de filtrer, d’agréger ou de transformer des données sans avoir besoin d’écrire du code complexe ou en plusieurs étapes.
Dans cet article, vous apprendrez comment utiliser les sous-requêtes pour résoudre des problèmes courants, quels pièges éviter et comment optimiser vos performances. A la fin, vous pourrez choisir le formulaire qui correspond le mieux à vos besoins : EXISTS, IN, ANY, ALL, SELECT… INTO, ou encore une sous-requête corrélée.
Les différents types de sous-requêtes
Les sous-requêtes s’imbriquent naturellement dans l’instruction SQL, mais chaque type possède des caractéristiques spécifiques. Les principales manipulations sont répertoriées ci-dessous:
1. Sous-requêtes pour l’élévation (scalaire)
Une sous-requête scalaire renvoie une valeur unique (une ligne et une colonne). Il est souvent utilisé dans la clause SELECT ou WHERE lorsque vous avez besoin d’une valeur calculée dans un autre tableau.
SELECT
e.id,
(SELECT MAX(salary) FROM salaries WHERE employee_id = e.id) AS max_salary
FROM employees e;2. Sous-requêtes IN
La clause IN compare la valeur d’une colonne avec un ensemble de valeurs obtenues par la sous-requête.
SELECT name FROM customers
WHERE city IN (SELECT city FROM cities WHERE population > 1_000_000);3. Sous-requêtes EXISTE (ou NON EXISTE)
Explore la présence ou l’absence de lignes renvoyées par la sous-requête. Idéal pour tester l’existence d’une relation.
SELECT name FROM customers c
WHERE EXISTS (SELECT 1 FROM orders o WHERE o.customer_id = c.id);4. ANY/ALL sous-requêtes
Ces opérateurs comparent plusieurs valeurs avec une seule valeur à l’aide d’opérateurs de commande (=, <, >etc.). Les sous-requêtes ANY/ALL vous permettent de remplacer très fréquemment des jointures ou des agrégations.
SELECT name FROM products
WHERE price > ALL (SELECT price FROM discounts WHERE discount_type = 'seasonal');5. Sous-requêtes corrélées
Contrairement à une sous-requête non corrélée, une sous-requête corrélée dépend d’une ou plusieurs colonnes de la requête principale. Il est évalué pour chaque ligne de la requête externe, ce qui peut affecter les performances.
SELECT e.name, e.salary,
(SELECT MAX(s.salary) FROM employees s WHERE s.salary > e.salary) AS higher_salary_exists
FROM employees e
WHERE e.salary < 50000;6. Sous-requêtes avec SELECT ... INTO
Permet d’insérer le résultat d’une requête dans une nouvelle table temporaire ou permanente. Souvent utilisé pour créer des tables de travail.
SELECT employee_id, AVG(salary) AS avg_salary
INTO temp_avg_salary
FROM salaries
GROUP BY employee_id;Quand choisir une sous-requête plutôt qu’une jointure
La décision entre sous-requête et jointure dépend de la logique métier et de l’impact sur les performances. Voici quelques critères de décision :
| Critères | Sous-requête | Pour rassembler |
|---|---|---|
| Lisibilité | Très lisible pour des filtres simples | Plus clair pour les relations explicites |
| Performance | Peut être plus lent (exécution répétée) | Plusieurs fois plus rapide (sous-requête non corrélée) |
| Complexité | Idéal pour les agrégats connectés à une seule ligne | Idéal pour plusieurs parties |
Généralement, si vous devez tester l’existence d’une relation ou récupérer une seule valeur globale, préférez EXISTS ou une sous-requête scalaire. Si vous devez afficher plusieurs colonnes en même temps, utilisez JOIN C’est souvent plus direct.
Optimiser l’utilisation des sous-requêtes
Les sous-requêtes peuvent devenir des goulots d’étranglement si elles sont mal optimisées. Voici quelques bonnes pratiques:
1. Utiliser des index
L’index couvrant la colonne conditionnelle dans la sous-requête accélère la recherche. Par exemple :
CREATE INDEX idx_city_population ON cities(population);2. Évitez les sous-requêtes lourdes et non corrélées (par ex. SELECT * FROM)
Remplacer par EXISTS ou ajouter un index sur les colonnes WHERE de la sous-requête.
3. Limiter la plage de résultats
Appliquez les filtres les plus restrictifs le plus tôt possible, même dans la sous-requête. Cela réduit la cardinalité du jeu de résultats traité.
4. Utilisation LIMIT et OFFSET soigneusement
Ces clauses peuvent forcer le moteur à évaluer entièrement la sous-requête, même si vous n’en avez besoin que d’une petite partie. Si vous avez besoin d’une valeur unique, préférez TOP/SELECT TOP 1 ou des agrégats.
5. Tirer parti des plans d’exécution
Analyser le plan d’exécution (EXPLAIN ou outil équivalent) pour vérifier si la sous-requête est exécutée par lots ou ligne par ligne. Toute sous-requête corrélée peut être transformée en jointure ou CTE (WITH) pour améliorer le plan.
Sous-requêtes et CTE par rapport à TSQL
SQL Standard (ANSI) et SQL Server (Transact-SQL) proposent des variantes intéressantes :
| variante | Avantages | Limites |
|---|---|---|
| Sous-requête intégrée | Simple à écrire | Peut être difficile à optimiser |
| Expression de table commune (CTE) | Meilleure lisibilité, possibilité de récursion | Moins efficace que les sous-requêtes en cascade |
| Fonction table | Au-delà de la logique, possibilité de paramètres | Plus complexe à entretenir |
Exemple de CTE pour remplacer une sous-requête complexe:
WITH SalesCTE AS (
SELECT
o.customer_id,
SUM(od.quantity * od.unit_price) AS total_sales
FROM orders o
JOIN order_details od ON od.order_id = o.id
GROUP BY o.customer_id
)
SELECT c.name, s.total_sales
FROM customers c
JOIN SalesCTE s ON s.customer_id = c.id
WHERE s.total_sales > 1000;Erreurs courantes à éviter
- Renvoyer plusieurs lignes dans une sous-requête scalaire
→ Utiliser
INouANYau lieu de. - Oublier d’utiliser des surnoms
→ La confusion des identifiants empêche souvent le moteur de faire la distinction entre les tables.
- Sous-requêtes corrélées sans index
→ L’évaluation ligne par ligne peut transformer une requête très rapide en un enregistrement fastidieux.
- Requêtes très profondément imbriquées
→ La lisibilité en souffre et les plans d’exécution deviennent difficiles à lire et à optimiser.
Cas d’utilisation illustrés
1. Trouvez des clients sans commandes
SELECT name
FROM customers
WHERE NOT EXISTS (
SELECT 1
FROM orders
WHERE orders.customer_id = customers.id
);2. Récupérer les salariés dont le salaire dépasse la moyenne générale
SELECT e.name,
e.salary,
(SELECT AVG(salary) FROM employees) AS avg_salary
FROM employees e
WHERE e.salary > (SELECT AVG(salary) FROM employees);3. Répertoriez les produits les plus chers dans une catégorie
SELECT p.name, p.price, p.category_id
FROM products p
WHERE p.price = (
SELECT MAX(price)
FROM products
WHERE category_id = p.category_id
);4. Calculer les agrégats par groupe avec une sous-requête corrélée
SELECT c.id,
c.name,
(SELECT SUM(o.amount)
FROM orders o
WHERE o.customer_id = c.id) AS total_spent
FROM customers c;Conclusion : maîtriser les sous-requêtes, un atout essentiel
Les sous-requêtes sont bien plus que de simples faits amusants. Ils vous permettent d’écrire du code SQL élégant, de modulariser la logique métier et d’obtenir des performances optimales lorsqu’ils sont utilisés correctement. En maîtrisant les différents types et en appliquant les bonnes pratiques d’optimisation, vous transformerez vos requêtes en requêtes puissantes, lisibles et pérennes.
En pratiquant la conversion des requêtes de jointure en sous-requêtes et vice versa, vous consoliderez votre compréhension du fonctionnement interne des moteurs SQL. N’oubliez pas que la précision de votre indexation et la clarté de votre plan d’exécution sont des outils qui, combinés aux sous-requêtes, feront de vous un consultant SQL infaillible.
