InnoDB存储引擎开创性的设计了一个Insert Buffer，对于非聚集索引的插入或更新操作，不是每次直接插入或更新索引页，而是先判断插入的非聚集索引页是否在缓冲池中。如果在，则直接插入；如果不在，则放入一个Insert Buffer中。

        这时，数据库的非聚集索引实际上并没有插入或更新相应的叶子节点，而是存放在另外一个位置。然后数据库再以一定的频率和情况进行Insert Buffer和辅助索引叶子节点的merge(合并)操作，这时可以将多个插入合并到一个操作中，大大提高了对于非聚集索引插入的性能。

     Insert Buffer的使用必须要满足两个条件：

     1> 索引是辅助索引

     2> 索引不是唯一索引

    当满足上述两个条件的时，InnoDB存储引擎就会使用Insert Buffer，提高插入操作的性能。

监控Insert Buffer的使用情况：
mysql> show engine innodb status\G;
*************************** 1. row ***************************
-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 1, free list len 0, seg size 2, 0 merges
merged operations:
 insert 0, delete mark 0, delete 0
 

seg size：显示了当前 Insert Buffer的大小2*16KB=32KB；

free list len：显示了空闲列表的长度；

size ：大表了已经合并记录页的数量；

inserts：代表了合并的插入记录数量；

merges：代表了合并的次数，也就是实际读取页的次数；

merges：merges recs：代表了插入缓冲将对于非聚集索引页的离散IO大约降低了的百分比；

Insert Buffer存在的隐患：

1、当有大量的插入操作，完成后，索引还在Insert Buffer中，没有被merge到索引中。此时，如果数据库发生了宕机，如果数据库在重启之后，恢复的时间就需要很长。

2、在写密集的场景中，Insert Buffer可能会占用太多的缓冲池的大小，为此percona的引擎进行了修复和限制Insert Buffer的大小；

2、MySQL的索引大多还是聚集索引(cluster index)，其实聚集索引的成本还是很高的，这也是为什么很多数据库都不是太依赖它的重要原因，尤其是在DML操作上；MySQL为了弥补辅助索引带来的性能缺陷，提供了Insert Buffer的解决方案。由此，我猜测MySQL B+树的算法实现上并不优秀，否则就不会搞这么弯道超车的策略。