innoDB的关键特性二--针对索引的插入缓存Insert Buffer

Insert Buffer (插入缓存)，InnoDB储存引擎的关键特性之一。他并不是在内存中的缓存池的一部分，而是物理页的一部分，和一般的数据页一样。

在InnoDB中，若主键（插入聚集索引Primary Key）自增，那么在页中存储时，会按主键顺序的存放，所以数据是集中的，大部分在一页中，这样会减少磁盘的离散读取，提高速度。 
然而，当索引不唯一时，就需要使用辅助索引，而记录按主键是顺序的，对其他索引，如辅助索引，就不会是顺序的，再插入时就会慢，尤其是大批数据插入时。 

Insert Buffer 的设计思想是，当按辅助索引插入时先将记录放在Insert Buffer中，然后在后台慢慢的合并回辅助索引页中。

innodb buffer pool 包含的数据页类型有：索引页，数据页，undo页，插入缓冲（insert buffer),自适应哈希索引，innodb存储是锁信息，数据字典信息等，结构图如下:

一，插入缓冲（Insert Buffer/Change Buffer）：提升插入性能

      只对于非聚集索引（非唯一）的插入和更新有效，对于每一次的插入不是写到索引页中，而是先判断插入的非聚集索引页是否在缓冲池中，如果在则直接插入；若不在，则先放到Insert Buffer 中，再按照一定的频率进行合并操作。这样通常能将多个插入合并到一个操作中，提升插入性能。使用插入缓冲的条件：

* 非聚集索引

* 非唯一

插入缓冲最大使用空间为1/2的缓冲池大小，不能调整大小，在plugin innodb中，升级成了Change Buffer。不仅对insert，对update、delete都有效。其参数是：

innodb_change_buffering，设置的值有：inserts、deletes、purges、changes（inserts和deletes）、all（默认）、none。

可以通过参数控制其使用的大小：

innodb_change_buffer_max_size，默认是25，即缓冲池的1/4。最大可设置为50。在5.6中被引入。

上面提过在一定频率下进行合并，那所谓的频率是什么条件？

1）辅助索引页被读取到缓冲池中。正常的select先检查Insert Buffer是否有该非聚集索引页存在，若有则合并插入。

2）辅助索引页没有可用空间。空间小于1/32页的大小，则会强制合并操作。

3）Master Thread 每秒和每10秒的合并操作。

mysql> show variables like '%change_buffer%';
+-------------------------------+-------+
| Variable_name                 | Value |
+-------------------------------+-------+
| innodb_change_buffer_max_size | 25    |
| innodb_change_buffering       | all   |
+-------------------------------+-------+
2 rows in set (1.03 sec)

有几个问题需要回答

1：为什么会有insert buffer,insert buffer能帮我们解决什么问题？

2：insert buffer有什么限制，为什么会有这些限制？

先说第一个问题。

举个现实中的例子来做说明，我们去图书馆还书，对应图书馆来说，他是做了insert(增加)操作，管理员在1小时内接受了100本书，这时候他有2种做法把还回来的书归位到书架上

1）每还回来一本书，根据这本书的编码（书柜区-排-号）把书送回架上

2）暂时不做归位操作，先放到柜面上，等不忙的时候，再把这些书按照书柜区-排-号先排好，然后一次性归位

用方法1，管理员需要进出（IO）藏书区100次，不停的登高爬低完成图书归位操作，累死累活，效率很差。

用方法2，管理员只需要进出（IO）藏书区1次，对同一个位置的书，不管多少，都只要爬一次楼梯，大大减轻了管理员的工作量。

所以图书馆都是按照方法2来做还书动作的。但是你要说，我的图书馆就20本书，1个0.5米的架子，方法2和1管理起来都很方便，这种情况不在我们讨论的范围。当数据量非常小的时候，就不存在效率问题了。

 

关系数据库在处理插入操作的时候，处理的方法和上面类似，每一次插入都相当于还一本书，它也需要一个柜台来保存插入的数据，然后分类归档，在不忙的时候做批量的归位。这个柜台就是insert buffer.

我想这就是为什么会有insert buffer，更多的是处于性能优化的考虑。

 

再说第二个问题，有什么限制：“只对于非聚集索引（非唯一）的插入和更新有效”

为什么对于非聚集索引（非唯一）的插入和更新有效?

还是用还书的例子来说，还一本书A到图书馆，管理员要判断一下这本书是不是唯一的，他在柜台上是看不到的，必须爬到指定位置去确认，这个过程其实已经产生了一次IO操作，相当于没有节省任何操作。

所以这个buffer只能处理非唯一的插入，不要求判断是否唯一。聚集索引就不用说了，它肯定是唯一的，mysql现在还只能通过主键聚集。

 

在MYSQL里面，insert buffer的大小在代码里面设定的最大可以到整个innodb buffer pool size的50%。这其实是不科学的，能够想象一下一个100平米的图书馆，有50平米是做退书的柜台是什么样子的吗？

 

前面说到管理员图书归位的时候，他会选择在“不忙的时候”再去做，优先处理前台退书操作，这个在MYSQL里面是这样体现的：

1）每1秒，如果IO次数小于5，合并插入缓冲。

2）每10秒，IO次数小于200，合并最多5个插入缓冲。

插入缓冲带来的问题
　　任何一项技术在带来好处的同时，必然也带来坏处。插入缓冲主要带来如下两个坏处：
　　1）可能导致数据库宕机后实例恢复时间变长。如果应用程序执行大量的插入和更新操作，且涉及非唯一的聚集索引，一旦出现宕机，这时就有大量内存中的插入缓冲区数据没有合并至索引页中，导致实例恢复时间会很长。
　　2）在写密集的情况下，插入缓冲会占用过多的缓冲池内存，默认情况下最大可以占用1/2，这在实际应用中会带来一定的问题。