innodb insert buffer 插入缓冲区的理解

今天在做一个大业务的数据删除时，看到下面的性能曲线图

在删除动作开始之后，insert buffer 大小增加到140。对于这些状态参数的说明

有几个问题需要回答

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个插入缓冲。

innodb insert buffer 插入缓冲区的理解,布布扣,bubuko.com