tmp_orders is the real orders table, flag1 means something nobody remembers, and the promotions bridge has no UNIQUE key because everyone just knows not to double-join it. An assistant reading information_schema learns none of this. What it can't read, it guesses, and the guesses run clean.
In January 2025 Mark Zuckerberg told Joe Rogan that AI would replace Meta's mid-level engineers within the year. The same CEO had spent the prior five years burning $73 billion on Reality Labs, a bet made from the same C-suite-level read of the technology. The pattern in both: showroom demo, executive-grade claim, no SME with veto authority anywhere near the room when the bet got made.
Coinbase paid Datadog $65M in 2021. The number didn't come out of an internal cost review - it came out of Datadog's earnings call, when an analyst asked about a single 'large upfront bill' that didn't recur at the same level the next year. Smaller versions of the same pattern run on every team's account.
A payload column stored as LONGTEXT, the DDL says TEXT and the actual shape lives in a serializer class six repos away. Six years of writes, three format generations coexisting, and a JSON path generated from the column name that matches zero rows.
status TINYINT NOT NULL tells you the storage. It doesn't tell you that 1 means 'active' in one table, 'pending' in another, and 'has been processed' in a third. Or that half the tables soft-delete and the other half don't. Or that signup_date VARCHAR(10) arrives in three different formats depending on which year the row was written.
UUIDv4 is globally unique, needs no coordination, leaks no row-count information, and destroys write locality on every insert. Every new row lands at a random position in the B-tree, which means a random page load, a likely page split, and a secondary-index entry that's 16 or 36 bytes instead of 8. The fix is picking v7, storing it narrow, or keeping the UUID at the edge.
150 columns, no joins, no foreign keys to chase - every developer's secret dream. Until an UPDATE to last_login_at rewrites 6KB of row on every sign-in and the buffer pool holds four customers per page.
A query runs in 0.4 ms for a year as an index-only scan with heap fetches at zero. A feature request adds one column to the SELECT list. The next day the same query takes 1243 ms. Nothing else changed. The index is the same, the filter is the same, the data is the same. The select list just stopped being covered.
tmp_orders is the main orders table. old_price holds the current price. flag1 means something nobody remembers. Every mature schema drifts this way: names that stopped describing their data, conventions from three different eras, tables whose temporary prefix is locked in permanently. The fix isn't renaming; it's making the drift legible to the next reader.
WHERE YEAR(created_at) = 2025 scans every row in the table. WHERE created_at >= '2025-01-01' AND created_at < '2026-01-01' does an index range scan. Both return identical rows; one is orders of magnitude faster. The difference is a single function call that the query planner can't see past.