Profiler and process list
Two tools for the question "why is this slow?" — one looks at a query, the other at the server.
Query profiler
Click Profiler in the toolbar, or the Explain button in the SQL editor to send the statement you are working on straight to it. You can also choose the connection and database and paste a query in.
The plan comes back as a graph: one box per operation, connected to the inputs it draws from, so a join reads as one node pulling from two tables rather than as indentation. Each box carries the table, the access method, row counts and cost, with a coloured stripe weighting it against the most expensive node in the plan. Click a box for the full detail — conditions, index names, buffer counts.
The same plan is available as a tree, and as the server's raw output.
Estimated or measured
A badge above the plan says which you are looking at:
- Estimated — the planner's guess. Nothing was executed.
- Measured — the query really ran, and the node boxes show actual rows next to the estimates.
Tick ANALYZE to ask for a measured plan. Whether you can get one depends on the server, and NabuSQL reports what it settled for rather than quietly downgrading:
| Engine | Measured plans |
|---|---|
| MySQL 8.3+ | Yes, with the full graph |
| MariaDB 10.1+ | Yes, with the full graph |
| MySQL 8.0.18+ | Yes, but the server only returns text — no graph |
| Older MySQL / MariaDB | No — you get the estimate, labelled as such |
| PostgreSQL | Yes, with buffer counts |
| SQLite | No execution-time plan exists |
SQL Server
SQL Server returns a tabular estimated plan rather than a graph. Reading its real plan means SHOWPLAN_XML, which NabuSQL does not parse yet — the page says so instead of pretending.
Reading a plan
Nodes worth a second look are flagged with ⚠:
- Full table scan — the whole table is being read where you expected an index lookup.
- Low selectivity — an index was used but barely narrowed anything down.
- Estimate far off — the planner expected a different number of rows by an order of magnitude. Usually stale statistics, and the reason it chose the plan shape it did. Run ANALYZE on the table and try again.
Also worth looking for: a cost concentrated in one node — that is where to optimise first — and an index that exists but goes unused, usually because the WHERE clause wraps the column in a function or compares it against a different type.
After adding an index in Tables and columns, re-run the profiler and confirm the plan actually changed. An index that the planner ignores costs you writes and buys nothing.
Process list
Right-click a database and choose Process List to see what the server is doing right now: the connected sessions, the queries they are running and how long they have been running.
Kill terminates a session. That is the tool for a runaway query holding locks that the rest of the application is waiting on.
Killing a session rolls it back
An interrupted transaction is rolled back by the server, which on a long-running write can take as long as the statement itself. Check what the session is doing before you kill it.
A practical order
- The application is slow → Process list: is one query blocking everything?
- A specific query is slow → Profiler: where does its cost sit?
- Fix — index, rewritten
WHERE, different join order. - Re-run the profiler and confirm the plan changed.