Two correct transactions, locally fine in isolation, kill each other. The cycle forms in the global ordering across concurrent sessions, which no single query can see. The query in the error log isn't wrong; the lock it was waiting for isn't held by a misbehaving process. The bug is the interaction.
`SELECT * FROM users WHERE team_id != 3` returns 800 rows on a table of 1,000 users. The 200 missing rows have `team_id IS NULL`. No error, no warning, the SQL standard says the engine did the right thing, and the report based on it is wrong.
A query joins customers to orders to order_items, sums total_cents, and reports $4.2M for the quarter. Finance reports $3.0M from the billing system. The SQL is fine. The 1:N join to order_items duplicated every order total by the average items-per-order, and SUM dutifully added them all up.
An aggregation that ran in 50ms yesterday takes 50 minutes today. No schema change, no query change. EXPLAIN ANALYZE shows a nested loop where there used to be a hash join. The planner's row estimate drifted 100x from reality between yesterday's ANALYZE and today's data. The fix is statistics, not the query.
A column called `status TINYINT NOT NULL` in a table you've never seen. Is `1` active? Pending? Enabled? Is `0` deleted or just inactive? The column type doesn't tell you. Neither does the column name. The fix is one line of DDL nobody writes.
An `INSERT INTO order_items (order_id) VALUES (9999)` against an order_id that doesn't exist. With a foreign key the database rejects the row. Without one, the row lands and the corruption surfaces months later when finance can't reconcile a report or backups have already rotated past the window.