QueryTuning.org
Database Query Performance Reference
Coverage
PostgreSQL SQL Server MySQL Oracle
Featured Story
SQL Server Query Performance Plan Cache
The SET Options Your Application Sets Without Telling You — and How They Silently Break Query Performance
Your DBA runs the query in SSMS in 200ms. The application runs the same SQL in 8 seconds. Same parameters, same server, different plan. The culprit is almost always ARITHABORT OFF on the application driver causing a plan cache split. Full diagnosis: bitmask decode in sys.dm_exec_cached_plans, why filtered indexes stop working silently, and the fix that requires zero application code changes.
⏱ 13 min read · SQL Server 2016+ · Apr 7, 2026
Read the full story →
Also this week
PostgreSQLAutovacuum
The Autovacuum That Quietly Ate Our Entire IOPS Budget for Six Weeks
⏱ 14 min · PostgreSQL 10+
MySQLPost-Mortem
Our Read Replica Was 14 Hours Behind — Seconds_Behind_Master Said Zero
⏱ 10 min · MySQL 5.7+
PGSSMYOR
Lock Wait Emergency Runbook — All Four Databases
Runbook · All databases · Updated Apr 2026
By Database Engine
PostgreSQL 8 stories
The planner is brilliant and occasionally confidently wrong. Statistics drift, autovacuum falls behind, and the plan that worked yesterday takes a different path today.
SQL Server 9 stories
Plan cache splits, parameter sniffing, TempDB contention, blocking chains that trace back to one idle SSMS window. The execution plan shows everything.
MySQL 9 stories
InnoDB internals, gap locks, replication lag that Seconds_Behind_Master hides, and a buffer pool sized for a server a third as large.
Oracle 6 stories
Undo contention, shared pool exhaustion, parallel query consuming every CPU core, and the AWR report that tells you exactly where the time went.
Recent Stories
All stories →
SQL ServerPost-Mortem
58 Seconds Frozen on Black Friday — Full Blocking Post-Mortem
One developer, one forgotten SSMS query window, 847 checkout requests queued behind a shared lock for 58 seconds on the highest-traffic day of the year.
⏱ 11 min · SQL Server 2014+
OraclePost-Mortem
ORA-01555 Every Tuesday at 2 PM — Eleven Consecutive Weeks
By the time anyone investigated the database looked healthy. V$UNDOSTAT held the answer: a 22-minute report colliding with 40x normal undo volume.
⏱ 11 min · Oracle 11g+
PostgreSQLPost-Mortem
The Replication Slot That Filled the Disk While We Watched the Wrong Dashboards
Lag in bytes, lag in seconds, active senders — all healthy. The idle slot accumulating 47GB appeared on none of them.
⏱ 11 min · PostgreSQL 10+
SQL ServerPerformance
Same Stored Procedure. 40ms on Dev. 22 Seconds on Prod.
After a Monday restart the plan compiled on the first call — from the largest customer's batch. Every small-customer call after that used the same enormous plan.
⏱ 11 min · SQL Server 2014+
MySQLLocking
InnoDB Gap Locks — The Deadlock Between Rows That Didn't Exist Yet
Two transactions, different target rows, neither touching anything the other had written. REPEATABLE READ and a range query produced a gap lock blocking both inserts.
⏱ 10 min · MySQL 5.6+
OraclePost-Mortem
Parallel Query Ate All 64 CPU Cores and Killed Everything Else
One analyst query, one table with DEGREE DEFAULT, 64 parallel slaves, every OLTP query at 40-second latency.
⏱ 11 min · Oracle 12c+
More Stories
Browse all →
01
SQL ServerIndexing
We Had 47 Indexes on One Table. None of Them Were the Right One.
Years of following DMV suggestions built a table with 47 indexes and 800ms write latency. The audit queries that revealed which were unused, which were redundant, and the one index we actually needed.
⏱ 14 min · SQL Server 2014+
02
PostgreSQLMemory
work_mem at 1GB Triggered an OOM Kill on Every Reporting Query
Three sessions × 12 sort nodes × 1GB = 36GB from one parameter. The per-sort-node multiplication nobody does before setting work_mem globally.
⏱ 8 min · PostgreSQL 9.4+
03
SQL ServerPost-Mortem
A Single Sort Query Wrote 400GB to TempDB in 12 Minutes
No memory grant warning in SSMS — it ran against test data. In production the sort received 4GB, spilled immediately, and consumed every available TempDB IOPS.
⏱ 11 min · SQL Server 2016+
04
MySQLSchema
ALTER TABLE Took the Table Offline for 4 Hours Until We Used the Right Syntax
Wrong ALGORITHM= on a 200-million-row table. The moment it queued for a metadata lock, every read and write queued behind it.
⏱ 11 min · MySQL 5.6+
05
Oracle RACPost-Mortem
RAC Node Eviction at 2 AM: The Network Split Nobody Saw Coming
A 1,800ms interconnect latency spike during a maintenance window nobody told the DBA team about. CSS heartbeats missed, node 2 evicted, 847 sessions dropped.
⏱ 12 min · Oracle RAC 12c+
06
PostgreSQLIndexing
The Partial Index That Fixed a Reporting Query Nobody Could Crack for Two Years
A 200-million-row table, a filter on 0.3% of rows. The standard index was useless. A partial index containing only those rows dropped the query from 40 seconds to 180ms.
⏱ 9 min · PostgreSQL 9.5+
View all 32 stories →
The Runbook Newsletter
One story every Tuesday
A fully written database incident in your inbox. No summaries. Just the full story.
Emergency Runbooks
🔒 Lock Wait & DeadlockAll DBs
💾 Disk FullSoon
🔥 CPU at 100%Soon
🐢 Slow QuerySoon
📡 Replication LagSoon
Browse by Problem
Query Performance Locking Memory Disk & I/O Replication CPU Indexing High Availability