Risposta.

Storicamente, le attività di aggregazione e raggruppamento in SQL sono emerse frequentemente per generare report e analisi. Già nei database relazionali degli anni '80 comparivano funzioni aggregate di base (SUM, COUNT, AVG), ma con grandi volumi di dati, il classico GROUP BY si rallentava. Si creava un problema di scalabilità: le query con decine di milioni di record e molteplici gruppi bloccavano le tabelle e rallentavano le operazioni.

Il problema sta nel fatto che, con un approccio inefficace, il server SQL consuma molte risorse per l'ordinamento, le tabelle intermedie e la lettura da disco. È particolarmente difficile quando il raggruppamento avviene su più colonne o con un insieme dinamico di dati aggregati.

La soluzione consiste nella corretta costruzione degli indici sulle colonne raggruppate, nell'uso della partizione, nella "semi-aggregazione" e nell'ottimizzazione della struttura della query. Per attività di business analytics si usano frequentemente le Common Table Expressions (CTE) strutturate, le vista materializzate e le funzioni finestra.

Esempio di codice:

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;

Caratteristiche chiave:

Gli indici sulle colonne raggruppate accelerano radicalmente il GROUP BY
La memorizzazione di dati aggregati preliminari (summary) riduce il carico
Le VIEW materializzate semplificano e accelerano report complessi

Domande trappola.

La performance del GROUP BY dipende dall'ordine delle colonne nel SELECT?

No, l'ordine delle colonne nel SELECT non influisce sulla velocità; ciò che è critico è su quali colonne avviene il raggruppamento e se ci sono indici su di esse.

È obbligatorio indicare una funzione aggregata per ogni campo nel SELECT quando si utilizza GROUP BY?

Non è obbligatorio; se un campo è incluso nel GROUP BY, può essere restituito senza aggregazione. Se un campo non partecipa al raggruppamento, deve essere necessariamente aggregato.

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

È possibile annidare un GROUP BY all'interno di un altro per aggregazione multi-livello?

Sì, le CTE annidate o le sottoquery consentono di effettuare aggregazioni "multi-piano" con risultati intermedi.

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

Errori tipici e anti-pattern

GROUP BY su colonne non indicizzate o su un numero elevato di campi
Uso impreciso delle funzioni di aggregazione (ad esempio, valori NULL)
Aggregazione senza filtraggio (i dati non necessari non vengono esclusi)

Esempio dalla vita reale

Caso negativo

Un analista crea un report con molteplici GROUP BY su una tabella di 200 milioni di record senza indici e senza campionamento, tutto l'ufficio si "blocca" alle 9 di mattina. L'esecuzione richiede 40 minuti.

Vantaggi:

Non è necessaria una progettazione aggiuntiva

Svantaggi:

Carico catastrofico sul server, rallentamenti, bloccano tutte le altre query

Caso positivo

Un ingegnere utilizza CTE per un filtraggio preliminare, indici ben progettati sui campi necessari e suddivide l'aggregazione in più fasi. Il report viene generato in 5 secondi.