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.

The lesson behind it →
More on Indexes