MySQL-InnoDB关键特性

---

作者：刘仁鹏
参考资料：《MySQL技术内幕：InnoDB存储引擎》

---

1.插入缓冲

1.Insert Buffer

• 缓冲池中有Insert Buffer的信息，但Insert Buffer和数据页一样，也是物理页的一个组成部分
• 插入缓冲要解决的问题：B+树的特性决定了非聚集索引插入的离散性，通过插入索引来提高插入操作的性能
• 插入缓冲的实现：对于非聚集索引的插入或更新操作，不是每一次直接插入到索引页中，而是先判断插入的非聚集索引页是否在缓冲池中，若在，则直接插入；否则，先放入到一个Insert Buffer对象中，好似欺骗，然后再以一定的频率和情况进行Insert Buffer和辅助索引页子节点的merge操作。这是通常能将多个插入合并到一个操作中（因为在一个索引页中），以提高对非聚集索引插入的性能
• 使用Insert Buffer要满足的两个条件：

1. 索引是辅助索引

• 聚集索引的插入操作一般是顺序的，不需要磁盘的随机读取，速度是非常快的，不需要Insert Buffer来提高性能

2. 索引不是唯一索引

• 在插入缓冲时，如果去查找索引页来判断插入记录的唯一性，就会发生离散读取，从而使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|
  |---|

1. space：占4个字节，存储的是待插入记录所在表的表空间ID（space id）
2. marker：占1个字节，兼容老版本的Insert Buffer，略过
3. offset：占4个字节，表示页所在的偏移量

• 当一个辅助索引要插入到页（space，offset）时，如果该页不在缓冲池中，则先构造一个search key，再去Insert Buffer B+树中查询，最后将该记录插入到Insert Buffer B+树的叶子节点中
• 对于插入到Insert Buffer B+树叶子节点的记录，并不是直接插入，而是要按如下规则构造：
  |space|marker|offset|metadata|-----secondary index record-----|
  |---|

1. space、narker、offset含义与非叶子节点相同
2. 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可能发生在以下几种情况下：

1. 辅助索引页被读取到缓冲池时
2. Insert Buffer Bitmap页追踪到该辅助索引页已无可用空间时
3. 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+树（取决于树的高度，一般为3_{4层）一般为3}4次
• 自适应哈希索引（AHI：Adaptive Hash Index）：InnoDB会监控表上各索引页的查询，若观察到建立哈希索引可以带来速度提升，则会建立
• AHI是通过缓冲池中的B+树页构造而来，所以建立的速度很快，且不需要对整张表构建哈希索引
• InnoDB会自动根据访问频率和模式，自动地为某些热点页建立哈希索引
• 建立AHI的要求：

1. 对页的连续访问模式必须一样（即查询条件一样）
2. 必须是等值查询（不能是范围查询）
3. 对该模式访问了100次
4. 页通过该模式访问了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个，在传统机械磁盘下有显著优势
• 问题：

1. 是不是可能将不怎么脏的页进行了刷新，而该页稍后很快变成了脏页？
2. 固态硬盘有较高的IOPS，是否还需要此特性

• 可通过参数innodb_flush_neighbor控制是否启用该特性。建议机械硬盘启用，固态硬盘禁用