Risposta.

GROUP BY viene utilizzato per raggruppare righe e aggregare dati, ma se applicato in modo errato può causare seri errori o prestazioni non ottimizzate.

Punti chiave:

Nel SELECT sono consentite solo colonne da GROUP BY o funzioni aggregative.
In query complesse con più JOIN è possibile avere duplicati e aggregazione errata.
Ordine formale: GROUP BY viene eseguito dopo WHERE e prima di HAVING.
In assenza di indicizzazione sulle colonne di gruppo, la query può funzionare molto lentamente su grandi volumi di dati.
HAVING filtra già dopo l'aggregazione, mentre WHERE lo fa prima.

Esempio:

SELECT customer_id, COUNT(*) as orders
FROM orders
WHERE order_date >= '2024-01-01'
GROUP BY customer_id
HAVING COUNT(*) > 10;

Domanda insidiosa.

È possibile nel SELECT dopo GROUP BY fare riferimento a colonne che non sono state specificate né in GROUP BY né in una funzione aggregativa?

Risposta: No, questo porterà a un errore nella maggior parte delle implementazioni SQL (ad esempio, in MS SQL, PostgreSQL). Alcuni DB specifici possono restituire valori casuali e errati (soprattutto in MySQL con sql_mode 'ONLY_FULL_GROUP_BY' disattivato), ma questo comportamento è scorretto e non garantito dagli standard. Esempio corretto:

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

Esempi di veri errori dovuti all'ignoranza delle sfumature dell'argomento.

Storia

In un progetto di e-commerce, il report "ricavi per prodotti" è stato preparato con la query SELECT sku, price, SUM(qty) FROM orders GROUP BY sku. Non è stata considerata: price non era stato incluso in GROUP BY ed era al di fuori della funzione aggregativa, il risultato — MySQL restituiva il primo valore disponibile del prezzo, il che ha causato seri errori nel report durante le promozioni. Correzione — aggiungere price a GROUP BY, oppure utilizzare una funzione aggregativa.

Storia

In un progetto BI, un report complesso con più JOIN e GROUP BY veniva eseguito in 80 minuti invece dei previsti 3. Dopo un'analisi si è scoperto: mancavano indici sulla colonna di GROUP BY e filtraggio, creando enormi tabelle temporanee per l'aggregazione. Soluzione — ottimizzazione degli indici e riscrittura della query con espressioni di tabella.

Storia

Un sviluppatore ha utilizzato HAVING per filtrare valori su un attributo utente non aggregato. Di conseguenza, il server ha eseguito l'aggregazione su tutti i dati e poi li ha rimossi tramite HAVING, riducendo le prestazioni. Corretto — spostare questo controllo in WHERE per restringere il campione prima dell'aggregazione.

Quali insidie ci sono nell'utilizzo della costruzione GROUP BY in SQL, specialmente nell'aggregazione e nell'ottimizzazione di query complesse?

Risposta.

Domanda insidiosa.

Esempi di veri errori dovuti all'ignoranza delle sfumature dell'argomento.