The insert buffer in InnoDB buffers pending inserts for secondary index pages to avoid blocking on disk reads for those pages during secondary index maintenance. This feature has been renamed the change buffer for InnoDB in MySQL 5.5 as it has been enhanced to support more than inserts.
It works for me. But talk is cheap so I will provide a few numbers. You can confirm that it works in theory by running the insert benchmark with change/insert buffering enabled and disabled. Compare the results. I will do this myself today.
I can confirm that it works in practice by reviewing the output from SHOW INNODB STATUS. There is a section with a few insert buffer statistics. User sessions write entries to the insert buffer during secondary index maintenance when the leaf page to be updated is not in the buffer pool. A background thread reads leaf pages from disk to apply pending changes buffered in the insert buffer. The insert buffer is a b-tree protected by transactions that uses the space_id and block_id values for secondary index leaf pages as a key. SHOW INNODB STATUS has values for:
- inserts - the number of changes written to the insert buffer
- merged recs - the number of changes flushed from the insert buffer to disk
- merges - the number of disk reads done to flush changes from the insert buffer to disk
You can estimate the benefit from the insert buffer as the ratio: 1 - (merges / merged_recs). This is an estimate of the fraction of secondary index maintenance disk reads saved by using the insert buffer. For the example below the result is 0.62 and the insert buffer reduces reads by 62%. I checked another server and it reduced reads by 65%.
An example of the output:
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
...
149451588 inserts, 147593778 merged recs, 55607567 merges
PlanetMySQL Voting: Vote UP / Vote DOWN