共计 3107 个字符，预计需要花费 8 分钟才能阅读完成。
世界上最快的捷径，就是好高鹜远，本文已收录【架构技术专栏】关注这个喜爱分享的中央。
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 中。