Blog
monitoringUgur Demirel8 settembre 20268 min di lettura

Come monitorare le prestazioni delle query del database: trova e correggi le query lente prima che colpiscano i tuoi utenti

Le query lente sono tra le cause più comuni di downtime e cattive prestazioni, e restano invisibili finché qualcuno non se ne accorge. Scopri quali metriche contano, il SQL esatto che le rivela in PostgreSQL e MySQL, e come monitorare il tuo database 24 ore su 24.

Come monitorare le prestazioni delle query del database: trova e correggi le query lente prima che colpiscano i tuoi utenti

Una pagina lenta raramente è una pagina lenta. Nella maggior parte dei casi è una query lenta. La tua applicazione può essere ben progettata, la cache può essere calda e il frontend può essere veloce — ma un solo indice mancante o una sola query non ottimizzata può trasformare una richiesta da 50 millisecondi in un timeout di 5 secondi. A differenza di un crash improvviso, una query lenta raramente compare nei log degli errori. Degrada silenziosamente l'esperienza finché gli utenti non se ne vanno.

Monitorare le prestazioni delle query del database è diverso dal controllare se il database è attivo. Entrambi contano, ma rispondono a domande diverse. Questa guida passa in rassegna le metriche che rivelano le query lente, il SQL esatto per trovarle in PostgreSQL e MySQL e come tenerle d'occhio 24 ore su 24.

Due domande diverse: è attivo, ed è veloce?

Il monitoring del database si divide in due livelli. Il monitoring della disponibilità risponde a una domanda semplice: la tua applicazione riesce ancora a raggiungere il database e risponde in tempi ragionevoli? Il monitoring delle prestazioni delle query risponde a una domanda più difficile: quali query sono lente, perché lo sono e peggiorano man mano che i dati crescono? Servono entrambi — un database può essere perfettamente raggiungibile mentre una sola query fuori controllo mette in ginocchio la tua applicazione.

Le metriche che contano davvero

Prima di andare a caccia di query lente, decidi cosa stai misurando. Questi numeri distinguono un database sano da uno sul punto di causare un incidente:

  • Latenza delle query — quanto impiega una query, espressa come p50, p95 e p99. Un p50 di 10 ms con un p99 di 3 secondi significa che la maggior parte degli utenti sta bene, ma alcuni aspettano.
  • Throughput (QPS) — query al secondo. Un picco improvviso può rivelare una nuova funzionalità o un vicino rumoroso su infrastruttura condivisa.
  • Tasso di query lente — la quota di query che superano la tua soglia (per esempio 500 ms). È il numero che dovrebbe allertarti per primo.
  • Saturazione del connection pool — quando tutte le connessioni sono occupate, le nuove richieste attendono. Un tempo di attesa alto è spesso un sintomo di query lente, non una mancanza di connessioni.
  • Eventi di lock e deadlock — una singola transazione di lunga durata può bloccare tutto ciò che c'è dietro.

Trova le query lente in PostgreSQL

PostgreSQL ha uno strumento che fa gran parte del lavoro: l'estensione pg_stat_statements. Registra statistiche aggregate per ogni query eseguita, tra cui tempo totale, tempo medio e numero di chiamate. Attivala una volta e ottieni una classifica permanente delle tue query più lente.

  • Attiva l'estensione: esegui CREATE EXTENSION IF NOT EXISTS pg_stat_statements;, aggiungila a shared_preload_libraries e riavvia il server.
  • Ordina le query più lente per tempo medio: SELECT query, calls, mean_exec_time, max_exec_time FROM pg_stat_statements ORDER BY mean_exec_time DESC LIMIT 10;
  • Ingrandisci una singola query con EXPLAIN ANALYZE. Esegue la query e mostra il piano, così vedi se usa un indice o fa una scansione completa della tabella.
  • Fai attenzione a Seq Scan su tabelle grandi, a un grande scarto tra righe stimate e reali e a ordinamenti costosi — le tre cause più comuni di query PostgreSQL lente.

Trova le query lente in MySQL

MySQL mantiene uno slow query log che puoi attivare con poche impostazioni. Cattura ogni query che impiega più di long_query_time, il che lo rende il modo più rapido per trovare i peggiori colpevoli senza aggiungere uno strumento di monitoring.

  • Attivalo: SET GLOBAL slow_query_log = 1; SET GLOBAL long_query_time = 1; poi individua il file con SHOW VARIABLES LIKE 'slow_query_log_file';
  • Ispeziona un piano con EXPLAIN su qualsiasi SELECT. Guarda la colonna type — ALL significa scansione completa della tabella, di solito ciò che va corretto.
  • Controlla la copertura degli indici con SHOW INDEX FROM your_table; e cerca indici mancanti o inutilizzati.
  • Tieni d'occhio Threads_running e Threads_connected in SHOW STATUS; un numero crescente di thread attivi spesso significa che le query lente tengono aperte le connessioni.

Correggi la causa, non il sintomo

Trovare una query lenta è solo metà del lavoro. Le correzioni tendono a ricadere in poche categorie note:

  • Indice mancante — la causa più comune. Un indice sulle colonne WHERE e JOIN trasforma spesso una scansione completa in pochi millisecondi.
  • Il problema N+1 — un ORM che esegue una query per riga invece di una per l'intero insieme. Cerca molte piccole query quasi identiche nei tuoi log.
  • Over-fetching — selezionare colonne che non usi mai o righe che non ti servono. Limita i risultati e seleziona solo ciò che mostri.
  • Configurazione errata del connection pool — un pool troppo piccolo mette in coda le richieste; uno troppo grande può sovraccaricare il database. Regolalo sul traffico reale.

Sappilo prima dei tuoi utenti

Gli strumenti a livello di query ti dicono cosa è lento dentro il database. Non ti dicono se il database è raggiungibile dalla tua applicazione, né se una query di health-check risponde ancora mentre dormi. È qui che entra in gioco il monitoring esterno.

isthisthing.online ti permette di creare un Monitor MySQL o PostgreSQL che si collega al tuo database secondo un piano, esegue un check e misura il Response Time. Se il database smette di rispondere o un check supera il suo Timeout, ricevi un alert via Email, Slack o altri canali — prima che i tuoi utenti vedano un errore. Combinato con una timeline degli Incident e una Status Page pubblica, trasformi «il sito è diventato lento» in un messaggio che invii invece di ricevere.

Una checklist pratica

  • Attiva il logging delle query lente (PostgreSQL: pg_stat_statements; MySQL: slow_query_log).
  • Trova le tue 10 query più lente ed esegui EXPLAIN ANALYZE su ciascuna.
  • Correggi prima gli indici mancanti e il problema N+1 — danno i guadagni maggiori.
  • Imposta una soglia di latenza e allerta su di essa, non solo sugli errori.
  • Aggiungi un Monitor MySQL o PostgreSQL in isthisthing.online per monitorare disponibilità e Response Time dall'esterno.
  • Rivedi le metriche delle query dopo ogni deploy e ogni modifica dello schema.

Le query lente non si annunciano. Si accumulano finché il sito sembra lento, il database si satura e stai spegnendo un incendio che avresti potuto evitare. Monitora il tuo database da dentro e da fuori, e lascia che isthisthing.online te lo dica per primo.

Crea oggi il tuo primo Monitor. Apri il tuo account gratuito e cattura le query lente prima dei tuoi utenti.

Come monitorare le prestazioni delle query del database: trova e correggi le query lente prima che colpiscano i tuoi utenti