关于mysql:重要知识点InnoDB的插入缓冲

世界上最快的捷径，就是好高鹜远，本文已收录【架构技术专栏】关注这个喜爱分享的中央。

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

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

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

在进行数据插入时必然会引起索引的变动，汇集索引不用说，个别都是递增有序的。而非汇集索引就不肯定是什么数据了，其离散性导致了在插入时构造的一直变动，从而导致插入性能升高。

所以为了解决非汇集索引插入性能的问题，InnoDB 引擎发明了 Insert Buffer。

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

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

先说几个点：

一张表只能有一个主键索引，那是因为其物理存储是一个 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 列插入的是工夫类型数据，那其非汇集索引的插入也是程序的。

能够看出非汇集索引插入的离散性导致了插入性能的降落，因而 InnoDB 引擎设计了 Insert Buffer 来进步插入性能。

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

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

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

给内部的感觉如同是树曾经插入非汇集的索引的叶子节点，而其实是寄存在其余地位了

以肯定的频率和状况进行 Insert Buffer 和辅助索引页子节点的 merge（合并）操作，通常会将多个插入操作一起进行 merge，这就大大的晋升了非汇集索引的插入性能。

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

只有满足下面两个必要条件时，InnoDB 存储引擎才会应用 Insert Buffer 来进步插入性能。

那为什么必须满足下面两个条件呢？

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

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

咱们能够应用命令 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 也存在一个问题：

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

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

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 中。

关于mysql:重要知识点InnoDB的插入缓冲

Insert Buffer 的存储

Insert Buffer 的作用

汇集索引的插入

非汇集索引的插入

Insert Buffer 的到来

Insert Buffer 的应用要求：

Insert Buffer 信息查看

Insert Buffer 的问题

Insert Buffer 的优化

总结：