Innodb用insert buffer来“欺骗”，不立刻更新index叶子节点page，而是将这些更新buffer起来，因此对同一个page的更新可以一起做。Insert buffer只在non－unique keys时起作用，因为在做merge之前检查值是否是unique是不可能的。
Innodb buffer是由Innodb的系统表空间分配的。尽管它叫"buffer",其实它跟“doublewrite buffer”一样，事实上是表空间的空间。虽然它可以像其他page一样也缓存在buffer pool。这可能考虑到insert
buffer在事务提交后也幸存，甚至MySQL重启。 事实上merge完index page需要几周的时间，虽然通常也没这么久。
2种情况下insert buffer merge发生。1， 要求merege－ 如果访问insertbuffer中含有未merge记录的page， 这个page必须merge之后才能被使用。 这意味着insert buffer会使读操作减慢。2，
后台线程。当加载系统后很少有merge发生，如果系统空闲了merge进程会更加活跃。这种行为会引起有趣的结果，就像在你几乎不用系统，几乎没有IO的情况下，当remove 系统负载的时候你会看到持续几个小时甚至所有脏页flush完成还在做的高IO负载。 这是令人奇怪的事情。
通过show innodb status可以看到Insert Merge Buffer的状态。
-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 7545, free list len 3790, seg size 11336,
8075308 inserts, 7540969 merged recs, 2246304 merges
seg size 指segment总的分配大小，以页为单位。因此这里它的大小是11336＊16k＝180M。
free list 指不包括未merge的记录的页的数目
size指insert buffer中未merge的页数。
事实上页数对我们并没有多大的帮助，因为row大小的不同的话insert buffer中row的数目也不同。
http://dev.mysql.com/doc/refman/5.0/en/innodb-insert-buffering.html
主键是唯一标识符，新行是按主键升序插入的，这是数据库应用的共同情况。因此，向clustered index插入不需要磁盘的随机读。
相反，secondary index通常不是唯一的，向secondary index插入是以相对随机顺序的发生的。如果没有Innodb的特别机制这将会引起很多随机的磁盘I/O操作。
如果一个索引记录应该插入到非唯一的secondary index， Innodb会检查这个secondary index page是否在buffer pool中，如果在，Innodb 之间将塔插入index page。如果index
page不在bufffer pool， Innodb将该记录插入到一个专门的insert buffer结构。insert buffer保持足够小以便它能完全适应在buffer pool，插入操作会很快完成。
周期性的，insert buffer会被归并到数据库中的secondary index。 归并若干个插入到索引树的同一个page是可能经常发生的，这是为了节省磁盘I/O操作。有人测试过insert buffer能将插入速度提升15倍。
insert事务提交后insert buffer merging还可能在继续。事实上，服务器关闭后重启它也可能会继续。
当有许多secondary index必须更新，有许多行要插入，insert buffer merging会需要很多个小时。在这期间， 磁盘I/O会增加，这可能引起磁盘边界查询速度的巨降。另外一个重要的后台I/O操作是purge线程。
关于insert buffer性能测试，参考：
http://code.google.com/p/google-mysql-tools/wiki/InnodbIoInsert
from :http://blog.163.com/ali_xiaojun/blog/static/19510709620097553119346/