Antwoord.

Historisch gezien kwamen taken voor aggregatie en groepering in SQL vaak voor bij het genereren van rapporten en analytics. Al in de relationele DBMS van de jaren 80 verschenen basis aggregatiefuncties (SUM, COUNT, AVG), maar bij grote hoeveelheden gegevens vertraagde de klassieke GROUP BY. Er ontstond een schaalbaarheidsprobleem: verzoeken met tientallen miljoenen records en veel groepen blokkeerden tabellen en vertraagden de werking.

Het probleem is dat bij een inefficiënte aanpak de SQL-server veel middelen verbruikt voor sortering, tussenresultatetabellen en schijflezen. Vooral lastig is het wanneer groepering plaatsvindt over meerdere kolommen of met een dynamische set van te aggregeren gegevens.

De oplossing ligt in de juiste opbouw van indexen over de te groeperen kolommen, het gebruik van partitionering, "halfaggregatie" en optimalisatie van de querystructuur. Voor business analytics-taken worden vaak gestructureerde Common Table Expressions (CTE), gematerialiseerde views en vensterfuncties gebruikt.

Voorbeeldcode:

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;

Belangrijke kenmerken:

Indexen op de te groeperen kolommen versnellen GROUP BY drastisch
Opslag van vooraf geaggregeerde (samenvatting) gegevens vermindert de belasting
Gematerialiseerde VIEW's vereenvoudigen en versnellen complexe rapporten

Vragen met een valstrik.

Heeft de prestatie van GROUP BY invloed van de volgorde van de kolommen in SELECT?

Nee, de volgorde van de kolommen in SELECT heeft geen invloed op de snelheid; kritiek is alleen over welke kolommen wordt gegroepeerd en of er een index op staat.

Moet elk veld in SELECT bij GROUP BY een aggregatiefunctie hebben?

Niet noodzakelijk, als het veld is opgenomen in GROUP BY kan het zonder aggregatie worden weergegeven. Als het veld niet deelneemt aan de groepering, moet het wel worden geaggregeerd.

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

Kan een GROUP BY in een andere worden genesteld voor meerlaagse aggregatie?

Ja, geneste CTE of subquery's maken "meerdere lagen" aggregaties met tussenresultaten mogelijk.

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

Typische fouten en anti-patronen

GROUP BY op niet-geïndexeerde kolommen of over een groot aantal velden
Onzorgvuldig gebruik van aggregatiefuncties (bijvoorbeeld NULL-waarden)
Aggregatie zonder filtratie (onnodige gegevens worden niet afgestoten)

Voorbeeld uit het leven

Negatief geval

Een analist bouwt een rapport met meerdere GROUP BY op een tabel met 200 miljoen records zonder indexen en zonder splitsing van de steekproef; het hele kantoor "hangt" om 9 uur 's morgens. De uitvoering duurt 40 minuten.

Voordelen:

Geen overbodige stapsgewijze planning nodig

Nadelen:

Catastrofale belasting op de server, vertragingen, alle andere verzoeken stoppen

Positief geval

Een ingenieur gebruikt CTE voor voorafgaande filtratie, slimme indexen op de benodigde velden en splitst de aggregatie in meerdere fasen. Het rapport wordt binnen 5 seconden gebouwd.