MySQL InnoDB三大特性之 - 插入缓冲 博客分类： mysql
InnoDB存储引擎有三大特性非常令人激动，它们分别是插入缓冲、两次写和自适应哈希，本篇文章先介绍第一个特性 - 插入缓冲（insert buffer）
在上一篇《MySQL - 浅谈InnoDB存储引擎》中，我们可以看到在InnoDB的内存中有单独一块叫“插入缓冲”的区域，下面我们详细来介绍它。
请尊重知识，请尊重原创 更多资料参考请见 http://www.cezuwang.com/listFilm?page=1&areaId=906&filmTypeId=1
非聚集索引写性能问题
为了阐述非聚集索引写性能问题，我们先来看一个例子：
mysql>create table t (
id int auto_increment,
name varchar(30),
primary key (id));
请尊重知识，请尊重原创 更多资料参考请见 http://www.cezuwang.com/listFilm?page=1&areaId=906&filmTypeId=1
我们创建了一个表，表的主键是id，id列式自增长的，即当执行插入操作时，id列会自动增长，页中行记录按id顺序存放，不需要随机读取其它页的数据。因此，在这样的情况下（即聚集索引），插入操作效率很高。
但是，在大部分应用中，很少出现表中只有一个聚集索引的情况，更多情况下，表上会有多个非聚集的secondary index （辅助索引）。比如，对于上一张表t，业务上还需要按非唯一的name字段查找，则表定义改为：
请尊重知识，请尊重原创 更多资料参考请见 http://www.cezuwang.com/listFilm?page=1&areaId=906&filmTypeId=1
mysql>create table t (
id int auto_increment,
name varchar(30),
primary key (id),
key (name));
这时，除了主键聚合索引外，还产生了一个name列的辅助索引，对于该非聚集索引来说，叶子节点的插入不再有序，这时就需要离散访问非聚集索引页，插入性能变低。
请尊重知识，请尊重原创 更多资料参考请见 http://www.cezuwang.com/listFilm?page=1&areaId=906&filmTypeId=1
插入缓冲技术机制
为了解决这个问题，InnoDB设计出了插入缓冲技术，对于非聚集类索引的插入和更新操作，不是每一次都直接插入到索引页中，而是先插入到内存中。具体做法是：如果该索引页在缓冲池中，直接插入；否则，先将其放入插入缓冲区中，再以一定的频率和索引页合并，这时，就可以将同一个索引页中的多个插入合并到一个IO操作中，大大提高写性能。回忆一下在《MySQL - 浅谈InnoDB存储引擎》中提到的master thread主循环其中的一项工作就是每秒中合并插入缓冲（可能）。
这个设计思路和HBase中的LSM树有相似之处，都是通过先在内存中修改，到达一定量后，再和磁盘中的数据合并，目的都是为了提高写性能，具体可参考《HBase LSM树》，这又再一次说明，学到最后，技术都是相通的。
插入缓冲的启用需要满足一下两个条件：
1）索引是辅助索引（secondary index）
2）索引不适合唯一的
如果辅助索引是唯一的，就不能使用该技术，原因很简单，因为如果这样做，整个索引数据被切分为2部分，无法保证唯一性。
只要实现上面两个条件，Innodb存储引擎会使用插入缓冲。
请尊重知识，请尊重原创 更多资料参考请见 http://www.cezuwang.com/listFilm?page=1&areaId=906&filmTypeId=1
show engine innodb status;可以查看当前插入缓冲大小，seg size 表示当前插入缓冲大小。具体大小为 seg size*16KB
插入缓冲带来的问题
任何一项技术在带来好处的同时，必然也带来坏处。插入缓冲主要带来如下两个坏处：
1）可能导致数据库宕机后实例恢复时间变长。如果应用程序执行大量的插入和更新操作，且涉及非唯一的聚集索引，一旦出现宕机，这时就有大量内存中的插入缓冲区数据没有合并至索引页中，导致实例恢复时间会很长。
2）在写密集的情况下，插入缓冲会占用过多的缓冲池内存，默认情况下最大可以占用1/2，这在实际应用中会带来一定的问题。
请尊重知识，请尊重原创 更多资料参考请见 http://www.cezuwang.com/listFilm?page=1&areaId=906&filmTypeId=1
percona已经发布一些补丁来修复，修改IBUF_POOL_SIZE_PER_MAX_SIZE修改为3 ，则插入缓冲占用缓冲池大小会下降到1/3.