Fast Table Goes Slow

A 400 million row InnoDB table had a bigint auto-increment primary key. The team replaced it with a UUIDv4 primary key, and bulk insert throughput fell by roughly an order of magnitude while the table file grew much faster than the raw data. What best explains the regression?

UUIDv4 generation drains the kernel entropy pool and blocks on refills, so inserts are bottlenecked in the client process and the storage engine is never the limiting factor

Random keys scatter every insert across the whole clustered index, causing page splits, fragmentation and constant buffer pool misses instead of appending to one hot page

InnoDB must scan the full clustered index on every insert to prove the new UUID is not already present, and the cost of that scan grows as the table gets larger

Doubling the primary key from eight bytes to sixteen doubles the bytes copied into every secondary index, and that extra width by itself accounts for the tenfold drop