Réponse.

Historiquement, les tâches d'agrégation et de regroupement en SQL sont souvent survenues pour la génération de rapports et l'analyse. Déjà dans les SGBD relationnels des années 80, des fonctions d'agrégation de base (SUM, COUNT, AVG) apparaissaient, mais avec de grands volumes de données, le classique GROUP BY ralentissait. Le problème de scalabilité se posait : des requêtes avec des dizaines de millions d'enregistrements et de nombreux groupes bloquaient les tables et ralentissaient les opérations.

Le problème réside dans le fait qu'avec une approche inefficace, le serveur SQL consomme beaucoup de ressources pour le tri, les tables intermédiaires et la lecture depuis le disque. C'est particulièrement difficile lorsque le regroupement se fait sur plusieurs colonnes ou avec un ensemble dynamique de données à agréger.

La solution consiste en une construction appropriée des index sur les colonnes groupées, l'utilisation de la partition, de la "semi-agrégation" et l'optimisation de la structure de la requête. Pour les tâches d'analyse commerciale, on utilise souvent des Common Table Expressions (CTE) structurées, des vues matérialisées et des fonctions de fenêtre.

Exemple de code :

WITH PreAgg AS (
    SELECT customer_id, region, SUM(amount) AS total_amount
    FROM sales
    WHERE sale_date >= '2024-01-01'
    GROUP BY customer_id, region
)
SELECT region, COUNT(DISTINCT customer_id) AS customers, SUM(total_amount) AS region_amount
FROM PreAgg
GROUP BY region
ORDER BY region_amount DESC;

Caractéristiques clés :

Les index sur les colonnes groupées accélèrent radicalement GROUP BY
Le stockage de données préalablement agrégées (summary) réduit la charge
Les VUES matérialisées simplifient et accélèrent les rapports complexes

Questions pièges.

La performance de GROUP BY dépend-elle de l'ordre des colonnes dans SELECT ?

Non, l'ordre des colonnes dans SELECT n'affecte pas la vitesse, ce qui est critique, c'est sur quelles colonnes se fait le regroupement et s'il existe un index sur celles-ci.

Est-il obligatoire d'indiquer une fonction d'agrégation pour chaque champ dans SELECT lors de GROUP BY ?

Ce n'est pas obligatoire, si le champ est inclus dans GROUP BY, il peut être affiché sans agrégation. Si le champ n'est pas impliqué dans le regroupement, il doit être agrégé.

SELECT department, MIN(salary) FROM employees GROUP BY department;

Peut-on imbriquer un GROUP BY dans un autre pour une agrégation multi-niveaux ?

Oui, les CTE imbriqués ou les sous-requêtes permettent de réaliser des agrégations "multi-étages" avec des résultats intermédiaires.

WITH Step1 AS (
  SELECT customer, SUM(amount) AS cust_sum FROM orders GROUP BY customer
)
SELECT COUNT(*) FROM Step1 WHERE cust_sum > 10000;

Erreurs typiques et anti-modèles

GROUP BY sur des colonnes non indexées ou sur un grand nombre de champs
Utilisation imprudente des fonctions d'agrégation (par exemple, valeurs NULL)
Agrégation sans filtrage (les données non pertinentes ne sont pas supprimées)

Exemple de la vie réelle

Cas négatif

Un analyste construit un rapport avec de multiples GROUP BY sur une table de 200 millions d'enregistrements sans index et sans segmentation de l'échantillon, tout le bureau "se fige" à 9 heures du matin. L'exécution prend 40 minutes.

Avantages :

Pas besoin d'une phase de conception supplémentaire

Inconvénients :

Charge catastrophique sur le serveur, ralentissements, tous les autres requêtes se bloquent

Cas positif

Un ingénieur utilise CTE pour un filtrage préalable, des index appropriés sur les champs nécessaires et divise l'agrégation en plusieurs étapes. Le rapport est généré en 5 secondes.