重要，知识点：InnoDB的插入缓冲

世界上最快的捷径，就是脚踏实地，本文已收录【架构技术专栏】关注这个喜欢分享的地方。

InnoDB引擎有几个重点特性，为其带来了更好的性能和可靠性：

• 插入缓冲（Insert Buffer）
• 两次写（Double Write）
• 自适应哈希索引（Adaptive Hash Index）
• 异步IO（Async IO）
• 刷新邻接页（Flush Neighbor Page）

今天咱们的主题就是 插入缓冲（Insert Buffer）,因为InnoDB引擎底层数据存储结构式B+树，而对于索引咱们又有汇集索引和非汇集索引。

在进行数据插入时必然会引发索引的变化，汇集索引没必要说，通常都是递增有序的。而非汇集索引就不必定是什么数据了，其离散性致使了在插入时结构的不断变化，从而致使插入性能下降。

因此为了解决非汇集索引插入性能的问题，InnoDB引擎 创造了Insert Buffer。

Insert Buffer 的存储

看到上图，可能你们会认为Insert Buffer 就是InnoDB 缓冲池的一个组成部分。

重点：其实对也不对，InnoDB 缓冲池确实包含了Insert Buffer的信息，但Insert Buffer 其实和数据页同样，也是物理存在的（以B+树的形式存在共享表空间中）。

Insert Buffer 的做用

先说几个点：

• 一张表只能有一个主键索引，那是由于其物理存储是一个B+树。（别忘了汇集索引叶子节点存储的数据，而数据只有一份）

• 非汇集索引叶子节点存的是汇集索引的主键

汇集索引的插入

首先咱们知道在InnoDB存储引擎中，主键是行惟一的标识符（也就是咱们常叨叨的汇集索引）。咱们平时插入数据通常都是按照主键递增插入，所以汇集索引都是顺序的，不须要磁盘的随机读取。

好比表：

CREATE TABLE test(
	id INT AUTO_INCREMENT,
	name VARCHAR(30),
	PRIMARY KEY(id)
);

如上我建立了一个主键 id,它有如下的特性：

• Id列是自增加的
• Id列插入NULL值时，因为AUTO_INCREMENT的缘由，其值会递增
• 同时数据页中的行记录按id的值进行顺序存放

通常状况下因为汇集索引的有序性，不须要随机读取页中的数据，由于此类的顺序插入速度是很是快的。

但若是你把列 Id 插入UUID这种数据，那你插入就是和非汇集索引同样都是随机的了。会致使你的B+ tree结构不停地变化，那性能必然会受到影响。

非汇集索引的插入

不少时候咱们的表还会有不少非汇集索引，好比我按照b字段查询，且b字段不是惟一的。以下表：

CREATE TABLE test(
	id INT AUTO_INCREMENT,
	name VARCHAR(30),
	PRIMARY KEY(id),
	KEY(name)
);

这里我建立了一个x表，它有如下特色：

• 有一个汇集索引 id
• 有一个不惟一的非汇集索引 name
• 在插入数据时数据页是按照主键id进行顺序存放
• 辅助索引 name的数据插入不是顺序的

非汇集索引也是一颗B+树，只是叶子节点存的是汇集索引的主键和name 的值。

由于不能保证name列的数据是顺序的，因此非汇集索引这棵树的插入必然也不是顺序的了。

固然若是name列插入的是时间类型数据，那其非汇集索引的插入也是顺序的。

Insert Buffer 的到来

能够看出非汇集索引插入的离散性致使了插入性能的降低，所以InnoDB引擎设计了 Insert Buffer来提升插入性能 。

我来看看使用Insert Buffer 是怎么插入的：

首先对于非汇集索引的插入或更新操做，不是每一次直接插入到索引页中，而是先判断插入的非汇集索引页是否在缓冲池中。

若在，则直接插入；若不在，则先放入到一个Insert Buffer对象中。

给外部的感受好像是树已经插入非汇集的索引的叶子节点，而实际上是存放在其余位置了

以必定的频率和状况进行Insert Buffer和辅助索引页子节点的merge（合并）操做，一般会将多个插入操做一块儿进行merge，这就大大的提高了非汇集索引的插入性能。

Insert Buffer的使用要求：

• 索引是非汇集索引
• 索引不是惟一（unique）的

只有知足上面两个必要条件时，InnoDB存储引擎才会使用Insert Buffer来提升插入性能。

那为何必须知足上面两个条件呢？

第一点索引是非汇集索引就不用说了，人家汇集索引原本就是顺序的也不须要你

第二点必须不是惟一（unique）的，由于在写入Insert Buffer时，数据库并不会去判断插入记录的惟一性。若是再去查找确定又是离散读取的状况了，这样InsertBuffer就失去了意义。

Insert Buffer信息查看

咱们可使用命令SHOW ENGINE INNODB STATUS来查看Insert Buffer的信息：

-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 7545, free list len 3790, seg size 11336, 
8075308 inserts,7540969 merged sec, 2246304 merges
...

使用命令后，咱们会看到不少信息，这里咱们只看下INSERT BUFFER 的:

• seg size 表明当前Insert Buffer的大小 11336*16KB

• free listlen 表明了空闲列表的长度

• size 表明了已经合并记录页的数量

• Inserts 表明了插入的记录数

• merged recs 表明了合并的插入记录数量

• merges 表明合并的次数，也就是实际读取页的次数

merges：merged recs大约为1∶3，表明了Insert Buffer 将对于非汇集索引页的离散IO逻辑请求大约下降了2/3

Insert Buffer的问题

说了这么多针对于Insert Buffer的好处，但目前Insert Buffer也存在一个问题：

即在写密集的状况下，插入缓冲会占用过多的缓冲池内存（innodb_buffer_pool），默认最大能够占用到1/2的缓冲池内存。

占用了过大的缓冲池必然会对其余缓冲池操做带来影响

Insert Buffer的优化

MySQL5.5以前的版本中其实都叫作Insert Buffer，以后优化为 Change Buffer 能够看作是 Insert Buffer 的升级版。

插入缓冲（ Insert Buffer）这个其实只针对 INSERT 操做作了缓冲，而Change Buffer 对INSERT、DELETE、UPDATE都进行了缓冲，因此能够统称为写缓冲，其能够分为：

• Insert Buffer

• Delete Buffer

• Purgebuffer

总结：

Insert Buffer究竟是个什么？

• 其实Insert Buffer的数据结构就是一棵B+树。

• 在MySQL 4.1以前的版本中每张表有一棵Insert Buffer B+树

• 目前版本是全局只有一棵Insert Buffer B+树，负责对全部的表的辅助索引进行Insert Buffer

• 这棵B+树存放在共享表空间ibdata1中

如下几种状况下 Insert Buffer会写入真正非汇集索引，也就是所说的Merge Insert Buffer

• 当辅助索引页被读取到缓冲池中时
• Insert Buffer Bitmap页追踪到该辅助索引页已无可用空间时
• Master Thread线程中每秒或每10秒会进行一次Merge Insert Buffer的操做

一句话归纳下：

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