Ordre d'exécution SQL : Comprendre l'exécution des requêtes

Lorsque nous écrivons des requêtes SQL, nous suivons généralement un certain ordre. (Le langage SQL est connu pour être écrit de l'intérieur vers l'extérieur). Cependant, les moteurs SQL suivent un ordre d'exécution spécifique lors de la compilation des requêtes, qui est différent de l'ordre d'écriture habituel. Il est important de comprendre l'ordre d'exécution du langage SQL pour maîtriser l'optimisation des requêtes, améliorer la précision et les performances des requêtes et déboguer des problèmes complexes, comme vous le verrez.

Pour commencer, je vous recommande de suivre le cours Introduction à SQL et le cursus de compétences SQL Fundamentals de DataCamp pour apprendre les bases de SQL et comment extraire des données à l'aide de requêtes. L'aide-mémoire sur les bases de SQL sera un guide utile pour les fonctions SQL courantes permettant de filtrer et d'agréger des données.

Qu'est-ce que l'ordre d'exécution SQL ?

L'ordre d'exécution SQL fait référence à l'ordre dans lequel les différentes clauses de la requête sont évaluées. Il est utile de le comprendre car l'ordre d'exécution est généralement différent de la façon dont nous écrivons les requêtes SQL. Pour prendre l'exemple le plus simple, vous pourriez penser que dans le cas de SELECT * FROM database, la clause SELECT est évaluée en premier, mais en réalité l'ordre d'exécution commence avec la clause FROM.

Voici l'ordre d'exécution du code SQL. Dans la section suivante, nous examinerons les étapes en détail. 

• FROM/JOIN: Spécifie les tableaux à partir desquels les données doivent être extraites.
• OÙ: Filtre les lignes qui remplissent la condition avant de les regrouper.
• GROUP BY: Regroupe les lignes qui partagent une propriété.
• AYANT: Filtre les groupes sur la base de conditions, appliquées après le regroupement.
• SELECTIONNER: Spécifie les colonnes à extraire ou à calculer.
• DISTINCT: Supprime les lignes en double de l'ensemble des résultats.
• ORDER BY: Trie l'ensemble des résultats en fonction des colonnes spécifiées.
• LIMITE: Spécifie le nombre maximum de lignes à renvoyer.
• OFFSET: Spécifie le nombre de lignes à sauter avant de commencer à renvoyer des lignes.

Dans la requête suivante, j'ai ajouté des commentaires pour montrer lesquels sont évalués en premier. 

-- #6+7   SELECT DISTINCT department_id                                 
-- #1     FROM employees                                                
-- #2     JOIN orders ON customers.customer_id = orders.customer_id     
-- #3     WHERE salary > 3000                                          
-- #4     GROUP BY department 
-- #5     HAVING AVG(salary) > 5000 
-- #8     ORDER BY department 
-- #9     LIMIT 10 OFFSET 5 
-- #10    OFFSET 5 ROWS FETCH NEXT 10 ROWS ONLY; 

J'ai également créé un acrostiche qui pourrait vous aider : Pour les objectifs de travailet les obstacles , recherchez les opportunités d' apprentissage organiséde DataCamp.

Étapes de l'exécution d'une requête SQL

Bien que la plupart des requêtes SQL que nous écrivons commencent par l'instruction SELECT, l'ordre logique d'exécution commence par la clause FROM. Ici, je vais écrire des requêtes pour montrer l'ordre d'exécution de la requête . Cependant, gardez à l'esprit que ces requêtes sont incomplètes et ne seront pas compilées.

Clause FROM

Les requêtes SQL commencent le processus d'exécution par la clause FROM. Il s'agit généralement de la première étape puisque la base de données identifie les sources de données/tableaux. Lorsque plusieurs tableaux sont concernés, la requête SQL évalue également la condition JOIN pour combiner les tableaux spécifiés comme source de données.

La requête incomplète ci-dessous sélectionnerait d'abord les données du tableau customers à l'aide de la clause FROM et du tableau orders à l'aide de la clause JOIN.

FROM customers
JOIN orders ON customers.customer_id = orders.customer_id;

Clause WHERE

La clause WHERE est exécutée après les clauses FROM et JOIN pour filtrer les lignes sur la base de conditions spécifiques. Il est important de noter que les colonnes définies avec des alias dans la clause SELECT ne peuvent pas être référencées directement dans la clause WHERE puisqu'elle est traitée avant la clause SELECT. 

La requête ci-dessous utilise la clause WHERE pour filtrer les enregistrements des employés dont l'adresse bonus est supérieure à 5000.

FROM employees
JOIN departments ON employees.employee_id = departments.department_id
WHERE salary * 0.1 > 5000;

Clause GROUP BY

Après avoir filtré les lignes, SQL exécute la clause GROUP BY pour regrouper les résultats en fonction des colonnes spécifiées. Cette étape est généralement utilisée avec des fonctions d'agrégation telles que COUNT(), SUM(), et AVG() pour effectuer certains calculs sur les colonnes spécifiées.

La requête ci-dessous filtre d'abord les employés dont l'adresse salary est supérieure à 3,000, puis les regroupe par department et calcule le salaire moyen pour chaque groupe.

FROM employees e
JOIN departments d ON e.employee_id = d.department_id
WHERE e.salary > 3000
GROUP BY e.name, d.department_name;

Clause HAVING

La clause HAVING est similaire à la clause WHERE, mais elle est utilisée pour filtrer les données groupées après l'opération GROUP BY. Dans la requête ci-dessous, SQL regroupe employees par department, calcule le salaire moyen pour chaque groupe, puis filtre les groupes dont le salaire moyen est inférieur ou égal à 5,000. 

FROM employees
JOIN departments ON employees.employee_id = departments.department_id
WHERE salary > 3000
GROUP BY department_name
HAVING AVG(salary) > 5000;

Clause SELECT

La clause SELECT est l'endroit où SQL dérive les colonnes ou les expressions à retourner après l'exécution des étapes précédentes. Vous pouvez appliquer des opérations arithmétiques, des alias et des fonctions d'agrégation dans la clause SELECT.

La requête suivante utilise la clause SELECT pour récupérer les données name et bonus calculées comme salary * 0.1 à partir du tableau employees.

SELECT name, salary * 0.1 AS bonus
FROM employees
JOIN orders ON customers.customer_id = orders.customer_id
WHERE salary > 3000
GROUP BY name
HAVING AVG(salary) > 5000;

Clause DISTINCT

La clause DISTINCT est évaluée après la clause SELECT dans une requête. La clause DISTINCT est importante pour supprimer les enregistrements en double d'un tableau car elle renvoie des lignes uniques. La requête ci-dessous renvoie chaque department_id unique, en filtrant les doublons.

SELECT DISTINCT department_id
FROM employees
JOIN orders ON customers.customer_id = orders.customer_id
WHERE salary > 3000
GROUP BY department
HAVING AVG(salary) > 5000;

Clause ORDER BY

La clause ORDER BY permet de trier l'ensemble des résultats de colonnes ou d'expressions spécifiques. Contrairement à la clause WHERE, la clause ORDER BY peut utiliser les alias de colonnes définis dans la déclaration SELECT.

La requête ci-dessous trie la colonne bonus par ordre décroissant. Notez que le bonus a été défini dans l'instruction SELECT comme un alias d'une expression.

SELECT DISTINCT department_id
FROM employees
JOIN orders ON customers.customer_id = orders.customer_id
WHERE salary > 3000
GROUP BY department
HAVING AVG(salary) > 5000
ORDER BY bonus DESC;

Clause LIMIT/OFFSET

Les clauses LIMIT et OFFSET sont généralement les dernières à être exécutées dans une requête SQL afin de limiter le nombre de lignes à renvoyer. La clause LIMIT précise le nombre maximal de lignes à renvoyer et OFFSET précise le nombre de lignes à sauter avant de commencer à renvoyer des lignes.

La requête ci-dessous récupère les noms et les salaires des employés, les trie par salary dans l'ordre décroissant, et limite la sortie à 10 résultats en ignorant les 5 premières lignes.

SELECT DISTINCT department_id
FROM employees
JOIN orders ON customers.customer_id = orders.customer_id
WHERE salary > 3000
GROUP BY department
HAVING AVG(salary) > 5000
ORDER BY bonus DESC
LIMIT 10 OFFSET 5;
-- OFFSET 5 ROWS FETCH NEXT 10 ROWS ONLY --SQL SERVER / ORACLE

Les clauses LIMIT et OFFSET sont prises en charge dans les bases de données MySQL et PostgreSQL. Pour SQL Server et Oracle, vous utilisez OFFSET, ROWS FETCH, et ROWS ONLY pour limiter le nombre de lignes à renvoyer à partir d'une requête.

Consultez notre tutoriel sur l'utilisation de SQL OFFSET pour en savoir plus sur la pagination des données et la prise en charge spécifique aux bases de données des clauses OFFSET et LIMIT.

Ordre d'exécution SQL vs. Ordre d'écriture

Le langage SQL est un langage déclaratif, ce qui signifie que l'ordre d'exécution des requêtes diffère de l'ordre écrit. Ainsi, au lieu de spécifier comment effectuer une tâche, vous déclarez ce que vous voulez, et le moteur de la base de données décide de la meilleure façon d'y parvenir. Cette méthode diffère des langages de programmation impératifs comme Python ou Java, dans lesquels vous écrivez explicitement des instructions étape par étape pour l'exécution. 

La compréhension de l'ordre d'exécution SQL modifie la façon dont vous envisagez la construction des requêtes. Par exemple, imaginez que vous écrivez une requête pour filtrer les lignes en fonction d'un alias que vous avez créé dans la clause SELECT:

SELECT price * 0.9 AS discounted_price
FROM products
WHERE discounted_price > 100;

À première vue, cela semble logique, mais cela provoque une erreur. Pourquoi ? Parce que la clause WHERE est évaluée avant la clause SELECT dans l'ordre d'exécution de SQL. Pour y remédier, vous devez utiliser une sous-requête ou HAVING:

SELECT price * 0.9 AS discounted_price
FROM products
HAVING discounted_price > 100;

Pour en savoir plus sur WHERE et HAVING en particulier, lisez notre tutoriel : La différence entre WHERE et HAVING en SQL.

Erreurs courantes et meilleures pratiques

Bien que l'ordre d'exécution de la requête ne soit pas affecté par l'ordre d'écriture, il est essentiel de comprendre le flux d'exécution pour éviter les erreurs courantes et améliorer les performances de la requête. Les erreurs suivantes sont directement liées à une mauvaise compréhension de l'ordre d'exécution de SQL :

Erreurs courantes

Vous trouverez ci-dessous les erreurs les plus courantes qui peuvent nuire à la performance de vos requêtes.

• Utilisation des alias de colonnes dans la clause WHERE: La clause WHERE étant exécutée avant la clause SELECT, toute tentative d'utilisation d'un alias dans WHERE entraînera une erreur. Comprendre que SQL évalue WHERE avant la clause SELECT vous apprend que vous devez répéter l'expression complète au lieu de vous fier à un alias.

• Utiliser HAVING pour le filtrage des lignes au lieu de WHERE: La clause HAVING est exécutée après GROUP BY et est conçue pour filtrer les données agrégées. Si vous filtrez des données non agrégées, cette clause doit figurer dans la clause WHERE. Connaître la différence d'ordre d'exécution entre WHERE et HAVING vous aide à déterminer où chaque condition doit être placée.

• Utilisation incorrecte des agrégats dans un SELECT sans GROUP BY: Comme GROUP BY est exécuté avant HAVING ou SELECT, le fait de ne pas grouper vos données avant d'appliquer une fonction d'agrégation entraînera des résultats incorrects ou des erreurs. La compréhension de l'ordre d'exécution permet de comprendre pourquoi ces deux clauses doivent aller de pair.

• Ne pas utiliser correctement les alias dans la clause ORDER BY: Contrairement à la clause WHERE, la clause ORDER BY est évaluée après SELECT. Cela vous permet d'utiliser les alias créés dans SELECT pour le tri, vous évitant ainsi toute confusion en sachant quand les alias sont disponibles pour être utilisés.

Meilleures pratiques

Prenez en compte les meilleures pratiques suivantes pour vous assurer que vos requêtes s'exécutent comme prévu.

• Filtrez tôt avec WHERE: Étant donné que la clause WHERE est exécutée avant GROUP BY et JOIN, l'application précoce des filtres réduit le nombre de lignes traitées par les clauses suivantes, ce qui améliore les performances de la requête. En filtrant les données non agrégées le plus tôt possible, vous limitez les données qui doivent être regroupées ou jointes, ce qui permet d'économiser du temps de traitement.

• Pré-agrégation des données avant les jointures: Sachant que FROM et JOIN sont les premières clauses exécutées, la préagrégation des données à l'aide de sous-requêtes ou d'expressions de tableau communes (CTE) vous permet de réduire l'ensemble de données avant le processus de jointure. Cela permet de réduire le nombre de lignes traitées lors de la jointure.

• Optimisez ORDER BY avec les index: La clause ORDER BY étant l'une des dernières étapes exécutées, le fait de s'assurer que les colonnes triées sont indexées accélérera les performances de la requête en aidant la base de données à traiter les opérations de tri plus efficacement.

• Évitez les SELECT * dans les requêtes de production: La clause SELECT est exécutée après le filtrage, le regroupement et l'agrégation, de sorte que le fait de ne spécifier que les colonnes nécessaires minimise la quantité de données extraites, réduisant ainsi les frais généraux inutiles.

Conclusion

Il est important de comprendre l'ordre d'exécution du langage SQL pour écrire des requêtes efficaces, précises et optimisées. Nous avons examiné l'ordre logique d'exécution des requêtes en SQL et l'avons comparé à l'ordre écrit. Je vous encourage à vous entraîner à écrire différentes requêtes pour mieux comprendre l'ordre logique d'exécution. La maîtrise de ce concept améliorera considérablement votre capacité à dépanner et à optimiser les requêtes SQL.

Si vous cherchez à améliorer vos compétences en SQL, je vous recommande d'essayer le cursus Associate Data Analyst in SQL de DataCamp pour devenir un analyste de données compétent. La formation Reporting in SQL vous aidera également à maîtriser la création de rapports et de tableaux de bord complexes pour une présentation efficace des données. Enfin, vous devriez obtenir la certification SQL Associate pour démontrer votre maîtrise de l'utilisation de SQL pour résoudre des problèmes commerciaux et vous démarquer des autres professionnels.