Field Notes · 3 May 2026
Reading a Slow Query Log Without Chasing Ghosts
How we triage PostgreSQL and MySQL slow logs so the first fixes address real user pain rather than noisy one-off statements.
A slow log full of one-off administrative statements can send a team on a week-long hunt that never touches checkout. Duration alone is a weak ranking key.
Prefer impact over maximum duration
Multiply approximate calls per hour by typical duration. A 200 ms query firing two thousand times during lunch may matter more than a 12-second weekly report.
Group before you rewrite
Normalize literals and look for shared shapes. Ten entries that differ only by primary key are one problem. Fix the shape once.
Confirm on staging with realistic parameters
Plans change with data volume and bind values. If staging is a thin subset, say so in the ticket — optimistic plans are a common source of embarrassment after deploy.
Hand the list to humans in sprint order
Our Query Performance Review ends with a ranked backlog: impact, risk, and who owns the application change. The log is evidence, not the deliverable.