Ready-made queries
The questions a DBA asks a database they were just handed.
Every query below is the one the console installs in a click: indexes nobody uses, transactions stuck open, the statements that cost the most. Copy the SQL, or connect the database and run it with a button.
PostgreSQL
PostgreSQL health
Dead tuples, unused indexes, open transactions, lock waits, cache hit and the statements that cost the most.
- Dead tuples by tableTables where dead rows pile up against live ones. Above 20% the autovacuum is losing; above 50% reads are paying for it.
- Indexes never usedNon-unique indexes with zero scans since the last statistics reset, with the space they take. Each one is write cost with no read benefit.
- Transactions open for more than 5 minutesSessions holding a transaction open, including idle-in-transaction ones, which block vacuum and hold locks while doing nothing.
- Sessions waiting on a lockWho is waiting, on whom, and for how long. An empty result is the healthy one.
- Statements by total timeThe statements that cost the most in aggregate: mean time × calls. Optimising the top three usually moves the whole server.Needs something on the server
- Largest tablesTotal size including indexes and TOAST. The number to watch over weeks, not once.
- Cache hit ratioShare of reads served from shared buffers, for tables and for indexes. Below 99% on a warm OLTP server means the working set no longer fits.
- Connections by stateOpen sessions grouped by state against max_connections. A pile of idle sessions is a pool that is too big; a pile of active ones is a server that is too small.
- Sequences past 80% of their rangeAn integer sequence that reaches its maximum stops the inserts on that table. This catches it months earlier.
- Replication lagFor a primary with replicas: how far behind each one is, in bytes and in time. Empty on a server with no replicas.
MySQL
MySQL health
Fragmented tables, tables without a primary key, long-running queries, the statements that cost the most, and the buffer pool.
- Largest tables and their free spaceData, index and reclaimable space per table. A large data_free is fragmentation an OPTIMIZE TABLE would recover.
- Tables without a primary keyInnoDB builds a hidden key for these, replication row-based is slow on them, and online schema tools refuse them.
- Queries running for more than 60 secondsEverything in the process list that has been executing for over a minute.
- Statements by total timeAggregated by digest: the statement shapes that cost the most across all their calls.Needs something on the server
- Indexes never usedIndexes with no reads since the server started, from performance_schema. Restart resets the counters — trust it after a few days of uptime.Needs something on the server
- Connections by commandOpen sessions grouped by what they are doing, against max_connections.
- InnoDB buffer pool hit ratioShare of page reads served from memory. Below 99% on a busy server means the buffer pool is smaller than the working set.
SQL Server
SQL Server health
Blocking, missing and unused indexes, the queries burning CPU, wait statistics and table sizes.
- Blocked sessionsRequests waiting on another session, with both sides' text. Empty is healthy.
- Missing indexes the optimiser asked forThe engine's own suggestions, ranked by the improvement it expects. Treat the top few as candidates, not orders.
- Indexes written to but never readNon-clustered indexes with updates and no seeks, scans or lookups since the last restart.
- Queries by total CPUCached plans ranked by worker time across all executions.
- Top waits since restartWhat the server spends its time waiting on. Filters out the benign background waits.
- Largest tablesRows and reserved space per table, from partition stats.
- Sessions by statusUser sessions grouped by status (running, sleeping, dormant), from sys.dm_exec_sessions. Many sleeping sessions usually mean an oversized connection pool.