Cos'è il piano di esecuzione di una query?

Il piano di esecuzione di una query è l'output dell'ottimizzatore del motore di database: la sequenza concreta di operazioni fisiche, scansione di una tabella, accesso tramite indice o partizione, ordine in cui unire più tabelle, ordinamenti intermedi, che il motore eseguirà per rispondere a quella query specifica. Negli ottimizzatori basati sui costi, quelli di SQL Server, PostgreSQL, BigQuery e praticamente ogni motore moderno, l'ottimizzatore genera più piani candidati e assegna a ciascuno un costo stimato calcolato sulle statistiche della tabella, numero di righe e distribuzione dei valori, e sui percorsi di accesso disponibili, poi sceglie il piano con la stima più bassa. Il comando che lo mostra si chiama EXPLAIN nella maggior parte dei motori, con varianti come EXPLAIN ANALYZE per confrontare la stima con l'esecuzione reale. Chi scrive SQL lo usa per il debug, ma il piano è anche il documento che spiega perché una query costa quello che costa, non solo quanto impiega a rispondere.

Leggi anche: Partitioning e clustering · Due tecniche per ridurre i dati letti da una query, e quindi il tempo e il costo, in un data warehouse cloud.

Cosa si legge davvero in un piano

Il segnale più immediato è se un'operazione è una scansione completa della tabella (full table scan) o un accesso mirato, tramite indice, partizione o clustering. Su una tabella di miliardi di righe la differenza fra i due è di ordini di grandezza: è nel piano che si vede se un intervento di partitioning e clustering sta riducendo i dati letti. Su tabelle piccole o con filtri poco selettivi vale il contrario, e la scansione completa è il piano giusto: il piano non dice che la scansione è cattiva e l'indice buono, dice quanti dati l'operazione tocca davvero. Un secondo segnale è l'ordine dei join: eseguire prima i join e i filtri più selettivi, quelli che scartano più righe, tiene piccolo il risultato intermedio. Un terzo segnale, il più diagnostico, è lo scarto fra righe stimate e righe effettive, che compare solo eseguendo il piano con EXPLAIN ANALYZE: quando la stima e il numero reale divergono di un ordine di grandezza, la prima cosa da verificare sono le statistiche della tabella; se sono aggiornate, la causa è di solito una correlazione fra colonne che l'ottimizzatore assume indipendenti.

Un esempio enterprise

Una dashboard di vendita aperta da un centinaio di persone al giorno lancia la stessa query di aggregazione su una tabella non partizionata. Il piano di esecuzione rivela una scansione completa a ogni apertura: non un problema di logica SQL ma di layout fisico dei dati. Su un motore fatturato a consumo quella scansione, letta isolatamente, costa pochi centesimi. Moltiplicata per cento aperture al giorno e per un mese di utilizzo diventa, a titolo puramente illustrativo dell'ordine di grandezza e non come cifra misurata, più di cento euro al mese per una singola dashboard, generati da una query che nessuno ha mai definito lenta perché il tempo di risposta percepito resta accettabile. Il piano rende visibile questo costo prima che arrivi in fattura, ed è anche ciò che permette di verificare se una vista materializzata risolverebbe il problema spostando il costo dalla lettura al refresh.

Perché conta per chi decide

Un piano di esecuzione letto una volta al mese su ogni query ricorrente costosa è uno dei controlli più economici che una revisione FinOps possa fare, perché risale dal totale a consuntivo alla query che genera la spesa. Ma il piano ha un limite: quando una query resta costosa nonostante ogni riscrittura, indici aggiunti, ordine dei join corretto, statistiche aggiornate, il problema quasi sempre non è più la query, è il modello dei dati sottostante. Una tabella che mescola granularità diverse, o che nessuna partizione può davvero isolare perché ogni query filtra su colonne diverse, resta cara qualunque SQL ci si scriva sopra, e a quel punto la decisione da prendere riguarda l'architettura della tabella.