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.