Indexessenior8+ years
Why does a random UUID primary key hurt InnoDB in two distinct ways that it doesn't hurt PostgreSQL, and what does that say about choosing a primary key type?
PostgreSQL stores table rows in an unordered heap, and every index — including the primary key's — is a separate B-tree pointing into it by physical location; a random primary key only affects that one structure. InnoDB stores the table inside the primary key's own B-tree — the leaf pages of the clustered index are the actual rows — and every secondary index stores the primary key value (not a physical pointer) at its leaves, so a random UUID primary key hurts twice: it scatters row inserts across the whole clustered tree instead of appending to the end, and a wide key (16 bytes of UUID) gets copied into every single secondary index's leaf entries, making all of them bigger.
PreviousAn index exists on (customer_id, status, placed_at), but a query filtering on customer_id and ordering by placed_at DESC LIMIT 20 is still slow. Why, and how would you fix the index?Next PostgreSQL defaults to read committed and MySQL defaults to repeatable read. What does a plain SELECT actually see differently under each engine's default, and where does a service moved between them tend to break?