作者：刘仁鹏
参考资料：《MySQL技术内幕：InnoDB存储引擎》
1.插入缓冲
1.Insert Buffer
- 缓冲池中有Insert Buffer的信息，但Insert Buffer和数据页一样，也是物理页的一个组成部分
- 插入缓冲要解决的问题：B+树的特性决定了非聚集索引插入的离散性，通过插入索引来提高插入操作的性能
- 插入缓冲的实现：对于非聚集索引的插入或更新操作，不是每一次直接插入到索引页中，而是先判断插入的非聚集<font color="red">索引页</font>是否在缓冲池中，若在，则直接插入；否则，先放入到一个Insert Buffer对象中，好似欺骗，然后再以一定的频率和情况进行Insert Buffer和辅助索引页子节点的merge操作。这是通常能将多个插入合并到一个操作中（因为在一个索引页中），以提高对非聚集索引插入的性能
- 使用Insert Buffer要满足的两个条件：
- 索引是辅助索引
- 聚集索引的插入操作一般是顺序的，不需要磁盘的随机读取，速度是非常快的，不需要Insert Buffer来提高性能
- 索引不是唯一索引
在插入缓冲时，如果去查找索引页来判断插入记录的唯一性，就会发生离散读取，从而使Insert Buffer失去了意义
Insert Buffer存在的一个问题：在写密集的情况下，插入缓冲会占用过多的缓冲池内存：默认最大可以占用到1/2的缓冲池内存。这可能给其他操作带来影响。可通过修改参数IBUF_POOL_SIZE_PER_MAX_SIZE为n，来表示插入缓冲最大只能使用1/n的缓冲池内存。
2.Change Buffer
- Change Buffer是Insert Buffer的升级，可以对所有DML操作都进行缓冲。
- 对应关系：INSERT（Insert Buffer）、DELETE（Delete Buffer）、UPDATE（Purge Buffer）
- Change Buffer适用的对象依然是非唯一的辅助索引
- InnoDB提供了参数innodb_change_buffering来表示开启各种Buffer的选项。可选值：inserts、deletes、purges、changes、all、none。默认值为all
- InnoDB提供参数innodb_change_buffer_max_size来控制Change Buffer最大内存使用量。如果该值为25，表示最多适用1/4缓冲池内存。该参数最多有效值为50
3.Insert Buffer的内部实现
- Insert Buffer的数据结构是一棵全局的B+树。负责对所有表的非唯一辅助索引进行Insert Buffer。这棵B+树存放在共享表空间中（默认ibdata1）。因此试图通过独立表空间idb文件恢复表中数据时，往往会CHECK TABLE失败。这是因为表的辅助索引中的数据可能还在Insert Buffer中（共享表空间中）。所以通过ibd文件进行恢复后，还需要通过REPAIR TABLE操作重建辅助索引
- Insert Buffer B+树的非叶子节点存放的是查询的search key（键值），构造如下：
|space|marker|offset|
|---|
- space：占4个字节，存储的是待插入记录所在表的表空间ID（space id）
- marker：占1个字节，兼容老版本的Insert Buffer，略过
- offset：占4个字节，表示页所在的偏移量
- 当一个辅助索引要插入到页（space，offset）时，如果该页不在缓冲池中，则先构造一个search key，再去Insert Buffer B+树中查询，最后将该记录插入到Insert Buffer B+树的叶子节点中
- 对于插入到Insert Buffer B+树叶子节点的记录，并不是直接插入，而是要按如下规则构造：
|space|marker|offset|metadata|-----secondary index record-----|
|---|
- space、narker、offset含义与非叶子节点相同
- metada：占用4个字节，存储内容如下：
|名称|字节|
|---|---|
|IBUF_REC_OFFSET_COUNT|2|
|IBUF_REC_OFFSET_TYPE|1|
|IBUF_REC_OFFSET_FLAGS|1|
IBUF_REC_OFFSET_COUNT是保存两个字节的整数，用来排序每个记录进入Insert Buffer的顺序，通过这个顺序回放，才能得到记录的正确值
- 为保证每次merge Insert Buffer页必须成功，需要有一个特殊的页来标记每个辅助索引页（space,offset）的可用空间。这个页的类型为Insert Buffer Bitmap
- 每个Inset Buffer Bitmap页用来追踪16384个辅助索引页，即256个区，每个Inset Buffer Bitmap页都在16384个页的第2个页中。
- 每个辅助索引页在Insert Buffer Bitmap页中占用4位：
|名词|大小(bit)|说明|
|---|---|---|
|IBUF_BITMAP_FREE|2|表示该辅助索引页中的可用空间数量，可取值为：
0：无可用剩余空间
1：剩余空间大于1/32页(512字节)
2：剩余空间大于1/16页
3：剩余空间大于1/8页|
|IBUF_BITMAP_BUFFERED|1|1表示该辅助索引页有记录被缓存在Insert Buffer B+树中|
|IBUF_BITMAP_IBUF|1|1表示该页为Insert Buffer B+树的索引页|
4.Merge Insert Buffer
- Merge Insert Buffer可能发生在以下几种情况下：
- 辅助索引页被读取到缓冲池时
- Insert Buffer Bitmap页追踪到该辅助索引页已无可用空间时
- Master Thread（随机选取以保证公平性）
2.两次写
两次写带给InnoDB数据页的可靠性
部分写失效：比如16K的页，只写了前4K，之后就发生了宕机。会导致数据丢失
两次写的存在必要性：虽然重做日志可以进行数据恢复，但必须意识到，重做日志中记录的是对页的物理操作（例如偏移量800处写‘aaaa’记录），当页本身损坏时，重做是没有意义的。在应用重做日志前，用户需要一个页的副本，当部分写失效时，必须先通过页的副本来还原该页，再进行重做
-
两次写的体系架构：
3242.png-59.8kB doublewrite由两部分组成，一部分是内存中的doublewrite buffer，大小为2M；另一部分是物理磁盘上共享表空间中连续的128个页，即2个区，大小同样为2M
对缓存池中的脏页进行刷新时，并不直接写磁盘，而是会通过memcpy函数将脏页先复制到内存中的doublewrite buffer中，之后通过doublewrite buffer再分两次，每次1M顺序的写入共享表空间的物理磁盘上，然后马上调用fsync函数，同步磁盘
上述过程中，因为doublewrite页是连续的，因此这个过程是顺序写的，开销并不大
在完成doublewrite页的写入后，再将doublewrite buffer中的页写入各个表空间文件中，此时的写入则是离散的
可通过如下命令观察doublewrite运行的情况：
SHOW GLOBAL STATUS LIKE 'innodb_dblwr%'\G
- 当OS将页写入磁盘时宕机，恢复时，InnoDB可从共享表空间的doublewrite中找到该页的一个副本，将其复制到表空间文件，再应用重做日志恢复
- 有些文件系统（如ZFS）本身就提供了部分写失效的防范机制，此时用户就不需要启用doublewrite了，可通过skip_innodb_doublewrite参数禁用doublewrite
3.自适应哈希索引
- 哈希查找的时间复杂度为O(1)，即一次查询就能定位数据；而B+树（取决于树的高度，一般为34层）一般为34次
- 自适应哈希索引（AHI：Adaptive Hash Index）：InnoDB会监控表上各索引页的查询，若观察到建立哈希索引可以带来速度提升，则会建立
- AHI是通过缓冲池中的B+树页构造而来，所以建立的速度很快，且不需要对整张表构建哈希索引
- InnoDB会自动根据访问频率和模式，自动地为某些热点页建立哈希索引
- 建立AHI的要求：
- 对页的连续访问模式必须一样（即查询条件一样）
- 必须是等值查询（不能是范围查询）
- 对该模式访问了100次
- 页通过该模式访问了N次，其中N=页中记录*1/16
- AHI是数据库自优化的，DBA无需也无法进行人为调整
- 可通过参数innodb_adaptive_hash_index禁用或启用该特性，默认启用
4.异步IO
- Sync IO：每进行一次IO操作，需要等待此操作结束才能继续接下来的操作
- AIO：（例如扫描多个索引页时）在发出一个IO请求后立即再发出另一个IO请求，当全部IO请求发送完毕后，等待所有IO操作的完成
- AIO的另一个优势：可以进行IO Merge操作。即将多个IO合并为1个IO，以提高IOPS的性能
- 老版本的AIO通过InnoDB代码模拟实现，新版本使用内核级别AIO（即native AIO）
- 参数innodb_use_native_aio控制是否启用Native AIO
5.刷新临近页
- 刷新临近页（Flush Neighbor Page）：当刷新一个脏页时，InnoDB会检查该页所在区的所有页，如果是脏页，则一起刷新
- 好处：通过AIO将多个IO操作合为1个，在传统机械磁盘下有显著优势
- 问题：
- 是不是可能将不怎么脏的页进行了刷新，而该页稍后很快变成了脏页？
- 固态硬盘有较高的IOPS，是否还需要此特性
- 可通过参数innodb_flush_neighbor控制是否启用该特性。建议机械硬盘启用，固态硬盘禁用
