Profiler ed elenco processi

Due strumenti per la domanda «perché è lento?» — uno guarda la query, l'altro il server.

Profiler delle query

Clicca Profiler nella barra degli strumenti, oppure il pulsante Explain nell' editor SQL per mandarci direttamente l'istruzione su cui stai lavorando. Puoi anche scegliere connessione e database e incollare una query.

Il piano arriva come grafo: un riquadro per operazione, collegato agli input da cui attinge, così un join si legge come un nodo che tira da due tabelle invece che come rientro. Ogni riquadro porta la tabella, il metodo di accesso, il numero di righe e il costo, con una banda colorata che lo pesa rispetto al nodo più costoso del piano. Clicca un riquadro per il dettaglio completo: condizioni, nomi degli indici, conteggi dei buffer.

Lo stesso piano è disponibile come albero e come output grezzo del server.

Stimato o misurato

Un'etichetta sopra il piano dice che cosa stai guardando:

• Stimato — l'ipotesi del pianificatore. Non è stato eseguito nulla.
• Misurato — la query è stata davvero eseguita, e i riquadri mostrano le righe reali accanto alle stime.

Spunta ANALYZE per chiedere un piano misurato. Se lo ottieni dipende dal server, e NabuSQL dichiara ciò con cui si è dovuto accontentare invece di ripiegare in silenzio:

Motore	Piani misurati
MySQL 8.3+	Sì, con il grafo completo
MariaDB 10.1+	Sì, con il grafo completo
MySQL 8.0.18+	Sì, ma il server restituisce solo testo — niente grafo
MySQL / MariaDB più vecchi	No — ottieni la stima, dichiarata come tale
PostgreSQL	Sì, con i conteggi dei buffer
SQLite	Non esiste un piano di esecuzione

SQL Server

SQL Server restituisce un piano stimato in forma tabellare anziché un grafo. Leggere il suo piano reale richiede SHOWPLAN_XML, che NabuSQL non interpreta ancora — la pagina lo dice invece di fingere un grafo.

Leggere un piano

I nodi che meritano un secondo sguardo sono segnalati con ⚠:

• Scansione completa della tabella — viene letta tutta la tabella dove ti aspettavi un accesso per indice.
• Bassa selettività — un indice è stato usato ma non ha ristretto quasi nulla.
• Stima molto lontana — il pianificatore si aspettava un numero di righe diverso di un ordine di grandezza. Di solito sono statistiche vecchie, ed è il motivo della forma del piano scelta. Esegui ANALYZE sulla tabella e riprova.

Vale la pena cercare anche un costo concentrato in un solo nodo — è lì che si ottimizza per primo — e un indice che esiste ma non viene usato, di solito perché la clausola WHERE avvolge la colonna in una funzione o la confronta con un tipo diverso.

Dopo aver aggiunto un indice in Tabelle e colonne, riesegui il profiler e conferma che il piano sia davvero cambiato. Un indice che il pianificatore ignora ti costa in scritture e non porta nulla.

Elenco processi

Clic destro su un database e Process List per vedere cosa sta facendo il server in questo momento: le sessioni collegate, le query in esecuzione e da quanto tempo girano.

Kill termina una sessione. È lo strumento per la query impazzita che tiene lock mentre il resto dell'applicazione aspetta.

Terminare una sessione comporta un rollback

Una transazione interrotta viene annullata dal server, e su una scrittura lunga questo può richiedere quanto l'istruzione stessa. Guarda cosa sta facendo la sessione prima di terminarla.

Un ordine pratico

1. L'applicazione è lenta → Elenco processi: c'è una query che blocca tutto?
2. Una query specifica è lenta → Profiler: dove si concentra il costo?
3. Correzione — indice, WHERE riscritto, ordine dei join diverso.
4. Riesegui il profiler e conferma che il piano è cambiato.