Random PRIMARY KEY for Innodb

Question

The article Slow INSERT into InnoDB table with random PRIMARY KEY column\'s value describes that if you use random PRIMARY KEY columns, insertions will be slow.

Answer 1

MySQL doesn't "rebuild" the index on each insert.

MySQL's default page size is 16K. It allocates these pages in 1MB increments (called extents).

When a table is first created (indexes are rebuilt), pages are filled up 15/16th full, leaving room for some random inserts (1k of room). If your index entries are 500 bytes each (primary key size + row data for a clustered index), that leaves room for 2 new rows to be inserted before having to split the page.

MySQL keeps the value of the highest and lowest record in the page header, so records within a certain range go on the same page.

When MySQL needs to insert a row on a full page, the page must be split. MySQL will add a new page, and move half of the page data to the new page.

Within a page, records may not actually be in physical order. They'll be in the order they were inserted. They're linked in order via a form of linked list. So, even a random insert, outside of the need to split the page, doesn't cause data to be physically moved around.

After many random inserts, your pages will be from 1/2 full to full. An index with many half full pages will negatively affect read performance (you have to read two half-full pages to read the same number of records as one 15/16th full page).

Now, if you're inserting rows in index order, then MySQL simply keeps adding to the end of the pages, filling them up 15/16 full, and adding an extent at a time of pages. Much less performance penalty since there is no splitting of pages, hence no moving of data is involved, not to mention the read performance benefit of nearly full pages.

Random inserts also increase fragmentation of the pages, which may affect read performance if you often read large numbers of sequential records (rare).

Also, change buffering may affect you.