为什么需要插入缓存Insert Buffer

磁盘中的主键索引由于天然自增，无须磁盘的随机 I/O，只需不断追加。但普通索引大概率无序，默认情况下需要进行随机磁盘 I/O 操作，效率极差

磁盘随机IO：B+数索引是按页存储的，随机IO就是随机访问页中的数据

因此需要插入缓存（Insert Buffer）解决普通索引插入效率低下的问题

非聚簇索引插入的离散性

《MySQL技术内幕》中有这样一句话”B+树的特性决定了非聚集索引插入的离散性“，下面先稍微理解下。

create table tb_user ( id int auto_increment, name varchar(20),age int unsigned,primary key (id),key(age)) engine=innodb  default charset=utf8;

上面建的表中有三个字段：

• id：自增主键
• age：普通key，等于是非聚集索引
• name：普通字段

往里面插入几条数据后如下：

此时，如果插入主键索引（递增），由于主键索引是有序递增的，连续插入的操作是连续的，比如id=6，7，8都依次插入到最后就行，B+树结构也不太会受影响（因为主键索引叶子节点也是按主键顺序存储），也不需要额外的磁盘随机IO，比较快。

如果插入非聚簇索引（二级索引）age的值，由于age列的数据是无序的，无法做到连续的索引插入到连续的行中，比如age=21， 22， 23，只能一条一条地定位和插入，这就是“离散”。在非聚簇索引的B+树中，叶子节点存储的是非聚簇索引与主键索引的值，虽然排序是按照age的大小，但插入操作并不是只考虑这个顺序，还是需要搜索定位到特定的**数据页（innoDB 数据页就是主键索引b+树的叶子节点，按主键索引顺序存储）**再插入，插入后还要考虑数据页容量大小决定是否分裂。

总之，主键索引由于自增特性，插入操作也是连续的，比较快；非聚簇索引字段在数据页中可能是无序，插入需要定位对应的数据页（主键索引B+树叶子结点），因此插入操作是离散的，相对较慢。

Insert Buffer

对于满足以下条件的索引：

• 非聚簇索引：因为聚簇索引，或者说主键索引一般是自增的且唯一的，插入操作连续，不存在非聚簇索引的问题
• 索引不唯一：索引唯一的话，每次插入还需要通过磁盘随机I/O判断插入索引值是否已存在

不直接插入到磁盘的索引叶中，先判断对应的非聚簇索引是否在Buffer Pool中，如果在则直接插入，否则先放入Insert Buffer中，然后以一定频率和辅助索引页子节点进行merge insert buffer，此时通常能将多个插入合并到一个操作中，因此能提高插入性能。

查看Insert Buffer信息

SHOW ENGINE INNODB STATUS

INSERT BUFFER AND ADAPTIVE HASH INDEX 下面就是insert buffer的信息，包括：

• seg size ：当前Insert Buffer的大小，就是多少个数据页（insert buffer本身就是一个B+树，一个数据页16KB）
• free listlen ：空闲列表的长度
• size ：已经合并记录页的数量
• Inserts ：插入的记录数
• merged recs ：合并的插入记录数量
• merges ：合并的次数，也就是实际读取页的次数

Insert Buffer的问题

因为Insert Buffer信息也存储在buffer pool中，在写密集的情况下，可能会占用过多的buffer pool（默认最大可以占用到1/2），影响其他使用buffer pool的操作

Change Buffer

就是MySQL 5.5 之后的升级版本，可以理解为对所有的表更改操作（INSERT、DELETE、UPDATE）都做buffer，包括：

• Insert Buffer
• Delete Buffer
• Purgebuffer

原来的Insert Buffer只对插入操作做buffer

总结

Insert Buffer 就是用于提升非聚集索引页的插入性能的，其数据结构类似于数据页的一个B+树，物理存储在共享表空间ibdata1中 。

Reference

https://cloud.tencent.com/developer/article/1735580

https://segmentfault.com/q/1010000013687775

https://zhuanlan.zhihu.com/p/333167012