Execution order, logical plans e query thinking

Una query SQL non è una lista di comandi da eseguire in fila. È una sequenza di trasformazioni logiche che il motore applica in un ordine preciso, diverso da quello in cui tu la scrivi. Quando ignori quell’ordine i bug diventano difficili da diagnosticare: un filtro che agisce troppo presto, una window function che calcola su un dataset già ridotto, un numero che sembra giusto e non lo è.

Ordine sintattico contro ordine di esecuzione

Molti analisti imparano SQL seguendo l’ordine in cui si digita: SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY. Quello è l’ordine di scrittura, non quello di esecuzione. Il motore segue invece un ordine logico standardizzato:

1. FROM (inclusi JOIN)
2. WHERE
3. GROUP BY
4. HAVING
5. WINDOW FUNCTIONS
6. SELECT
7. DISTINCT
8. ORDER BY
9. LIMIT/OFFSET

La conseguenza è che i filtri in WHERE riducono il dataset prima che le window function vengano calcolate. L’errore frequente è pensare che la window function veda tutte le righe originali e che il filtro successivo si limiti a tagliare il risultato. Non funziona così.

Un caso emblematico è quello di Zalando, dove un filtro errato sulle window function ha gonfiato la retention del 34% e ha portato a investimenti sbagliati.

Il piano logico come mappa mentale

Per leggere una query correttamente serve una mappa del suo piano logico, e quella mappa nasce da tre domande. Qual è il grain di partenza, per esempio una riga per transazione? Quali righe sopravvivono al WHERE? E come le trasformano i passaggi successivi, dal GROUP BY alla window function, dall’HAVING alla SELECT?

Con queste tre domande SQL smette di essere una sequenza di istruzioni e diventa una pipeline di trasformazioni su insiemi di dati, esattamente come lo intendeva Jim Gray.

La forma algebrica della query

Tradotta in algebra relazionale, una query generica segue questa catena:

• Join relazionale
• Filtro (σ)
• Aggregazione (γ)
• Filtro su gruppi (σ)
• Window function (ω)
• Proiezione (π)
• Ordinamento (τ)

Il punto da fissare è la posizione della window function (ω): agisce dopo il filtro e l’aggregazione, ma prima della proiezione e dell’ordinamento. Da lì derivano quasi tutti gli errori di chi la immagina applicata sui dati grezzi.

Il caso Shopify e la riconciliazione del GMV

Nel 2022 Shopify ha risolto un problema di riconciliazione del GMV. Indagando hanno scoperto due cose: il filtro WHERE escludeva ordini cancellati dopo la registrazione del pagamento, e la window function operava su dati già aggregati, gonfiando i valori cumulativi. La soluzione è stata ridefinire il grain e ricalcolare la finestra su dati non aggregati. È lo stesso schema della query mal letta: la finestra sembrava dare numeri plausibili perché lavorava nel punto sbagliato della pipeline.

Costruire l’analisi a tre profondità

Comincia con una scheda sintetica che descriva la decisione da supportare, la metrica principale, la baseline e il rischio più comune. Serve a non perdere il legame tra la query e la scelta che deve migliorare.

Poi sali di un livello. Costruisci una tabella con tre segmenti o periodi e per ciascuno indica cosa cambia, una spiegazione alternativa plausibile e un controllo da effettuare prima di concludere. Infine prepara un decision memo completo, con ipotesi, dati necessari, criteri di esclusione, controlli di qualità, soglia decisionale, rischio residuo e piano di monitoraggio.

Per gli esercizi usa dati di ordini, eventi, sessioni, coorti, revenue e tabelle calendario. Se non li hai, genera un dataset sintetico di almeno 200 righe con una dimensione temporale, una di segmento e una metrica.

L’errore che svuota l’analisi

Non usare “execution order” come etichetta vuota. Serve un processo concreto che colleghi l’analisi alla decisione. Se non dici quale scelta cambia, quale dato osservi e quale errore eviti, la lezione resta teoria. Il valore dell’ordine di esecuzione si vede solo quando ti impedisce di firmare un numero gonfiato.

Verifica di comprensione

Per controllare la presa, prova a rispondere. Perché l’ordine sintattico di SQL differisce dall’ordine di esecuzione? Dove si collocano le window function in quell’ordine e perché questo conta per i filtri? Come useresti il piano logico per fare debug, descritto in tre passaggi? E nel caso Shopify, quali problemi di grain sono stati risolti?

Riepilogo operativo

L’ordine di esecuzione, i piani logici e il modo di pensare le query servono a decidere con SQL in modo più consapevole. Non riguardano solo la correttezza della query, ma la comprensione di cosa misuri, come lo misuri e quali errori puoi evitare. Sono la guida per trasformare dati e assunzioni in scelte operative concrete.