Data Engineering09.09.26·9 min◉ Milano

Analisi performance database: metodo, metriche e interventi che funzionano · Milano

Risposta rapida

L'analisi delle performance di un database parte sempre dalle query, non dall'hardware: nell'80% dei casi il 90% del tempo di attesa è generato da meno di dieci istruzioni SQL. Il metodo corretto è misurare i tempi reali per query (durata totale, chiamate, righe lette per riga restituita), individuare le prime dieci per tempo cumulato, leggerne il piano di esecuzione e intervenire su indici e riscrittura prima di toccare CPU, RAM o storage.

◉ Contesto locale · Milano, Lombardia

Soim collabora con aziende milanesi su prodotti digitali su misura, real estate tech e KPI intelligence per finanza, servizi professionali e immobiliare.

Le metriche che contano davvero

Tempo cumulato per query (non tempo medio: una query da 40 ms chiamata 200.000 volte pesa più di una da 6 secondi eseguita una volta al giorno), righe lette per riga restituita, cache hit ratio, attese su lock, crescita delle tabelle e delle bloat pages, età delle statistiche. Metriche di sistema come CPU e I/O servono a confermare una diagnosi, non a formularla.

Come si trovano le query lente

Su PostgreSQL l'estensione pg_stat_statements ordinata per total_exec_time; su SQL Server le Query Store e le DMV sui piani in cache; su MySQL lo slow query log con long_query_time abbassato temporaneamente e pt-query-digest. Il primo passo è sempre lo stesso: una tabella delle dieci query che generano più tempo di attesa, con numero di chiamate. Da quella tabella nasce tutto il resto.

Leggere un piano di esecuzione senza perdersi

Tre cose bastano nella maggior parte dei casi: la presenza di scansioni sequenziali su tabelle grandi dove esiste un filtro selettivo, la differenza tra righe stimate e righe effettive (fattore superiore a 10 indica statistiche o distribuzione mal rappresentate), e l'ordine dei join con eventuali nested loop su volumi elevati. Il resto è ottimizzazione fine, utile solo dopo aver risolto questi tre.

Indici: quando aggiungerli e quando rimuoverli

Aggiungere un indice composito seguendo la selettività reale dei filtri e includendo le colonne restituite quando serve un index-only scan. Ma anche rimuovere: gli indici mai usati rallentano ogni scrittura e occupano cache. Su un database transazionale sano il rapporto tipico è 3-6 indici per tabella; sopra i dieci si sta pagando un costo su ogni INSERT senza guadagno in lettura.

Riscrittura delle query e struttura dati

Interventi con impatto maggiore: eliminare SELECT * su tabelle larghe, sostituire subquery correlate con join o CTE materializzate, spostare i filtri prima delle aggregazioni, paginare con chiavi ordinate invece di OFFSET elevati, precalcolare le aggregazioni pesanti in tabelle di riepilogo aggiornate di notte. Quest'ultimo punto è quello che tipicamente porta una dashboard da 20 secondi a meno di uno.

Quando il problema è davvero l'infrastruttura

Solo dopo aver sistemato le query: memoria insufficiente per tenere in cache l'indice più usato, storage con latenza elevata, connessioni non gestite da un pooler, manutenzione (VACUUM, aggiornamento statistiche, rebuild indici) mai pianificata. Scalare la macchina prima di questa verifica raddoppia il costo mensile e sposta il collo di bottiglia di qualche settimana.

Come interveniamo in Soim

Elaboriamo oltre un milione di record al giorno su database di clienti industriali e immobiliari. Un assessment tipico dura 3-5 giornate e consegna la tabella delle query critiche, i piani di esecuzione commentati, la lista di indici da creare e rimuovere e le stime di guadagno per intervento. Richiedi un audit dal form di contatto.

FAQ

Domande frequenti su analisi performance database

Quanto dura un'analisi delle performance di un database?

Da 3 a 5 giornate per un assessment su un singolo database in produzione, incluse la raccolta delle metriche su un ciclo settimanale completo e la stesura del piano di intervento.

Si può analizzare la performance senza fermare la produzione?

Sì. Le estensioni e i log di statistica lavorano su dati già raccolti dal motore; gli unici momenti da concordare sono l'eventuale creazione di indici su tabelle molto grandi, che su PostgreSQL si esegue in modalità concorrente.

Aggiungere RAM o CPU risolve le query lente?

Raramente in modo stabile. Più memoria maschera una query che legge dieci volte i dati necessari: il tempo cala per qualche settimana e torna al crescere dei volumi. Prima si corregge la query, poi si dimensiona la macchina.

Quali guadagni sono realistici dopo un intervento?

Sulle query critiche è comune un miglioramento tra 5 e 50 volte quando il problema è un indice mancante o una aggregazione ricalcolata a ogni richiesta; sui tempi complessivi di una dashboard il passaggio tipico è da decine di secondi a meno di due.

Continua a leggere

Data Analytics