KILL <connection_id>; -- kills the entire connection, not just the query She never forgot that 2 AM wakeup. And from then on, every SELECT on large tables had to justify its indexes in the design review. “With great SELECT comes great responsibility — and the ability to KILL QUERY when responsibility fails.”
Killing it was the only immediate option. No time for a graceful shutdown.
Almost six minutes. That single query was hogging the CPU, locking critical rows, and starving the checkout service.
| Id | User | Host | db | Command | Time | State | Info | |----|------|------|----|---------|------|-------|------| | 19283 | app_user | 10.2.3.4:54321 | shop | Query | 347 | Sending data | SELECT * FROM orders o JOIN order_items oi ON o.id = oi.order_id JOIN products p ON oi.product_id = p.id WHERE o.created_at > '2023-01-01' AND p.tags LIKE '%summer%' |
It was 2:13 AM on a Tuesday. Maya, the only on-call database engineer, jolted awake by a relentless buzz from her phone.
The next morning, Maya added a monitoring alert for queries running longer than 60 seconds. She also taught the dev team how to catch themselves:
Query OK, 0 rows affected (0.00 sec) She ran SHOW PROCESSLIST again. The row with Id 19283 was gone — replaced by a single line: KILLED (for a brief moment, then disappeared).
Almost instantly, CPU usage dropped from 98% to 12%. The API errors stopped. Her phone went quiet.
