第 17 章：Change Buffer 与 AHI

这是《MySQL 8.0 源码与内核实战》的独立章节版。本章从概念、实操和生产排查三个视角展开，代码块保留了原书可直接运行的版本。 Change Buffer 优化二级索引写入，AHI 加速热点页内记录定位。两者都受访问模式影响，并非总是有效。

17.1 Change Buffer

当二级索引页不在 Buffer Pool 时，InnoDB 可以先缓存插入或删除操作，避免立即读页。

insert secondary index
  -> page in buffer pool?
     |-- yes: modify directly
     +-- no:
        |-- unique index: must read page to check
        +-- non-unique: buffer change
           -> merge later

适用：

1. 非唯一二级索引；
2. 写多读少；
3. 索引页访问分散；
4. 二级索引较多；
5. 页不在内存。

不适合：

1. 唯一索引；
2. 写后立刻读；
3. 热点索引；
4. 内存充足且命中率极高；
5. 只读或大量顺序维护场景。

17.2 Merge

background or page access
  -> read index page
     -> apply buffered changes
        -> write redo
           -> remove change record

合并可能造成延迟抖动，尤其在读取冷索引或后台批量 merge 时。

观测：

SHOW GLOBAL STATUS LIKE 'Innodb_ibuf%';

关注：

1. merge 次数；
2. merge 耗时；
3. slot 使用；
4. size；
5. segment size。

17.3 参数

8.0 部分小版本对 change buffer 支持范围有变化，使用前应确认当前版本文档和源码条件。

17.4 AHI

自适应哈希索引为热点页建立索引项到记录位置的哈希缓存：

index tuple prefix
  -> hash
     -> page and record position

适用：

1. 等值查询；
2. 热点页；
3. 相同前缀模式；
4. 页内记录较多；
5. B+Tree 下降成本明显。

不适合：

1. 范围扫描；
2. 模式极其分散；
3. 写入频繁导致哈希维护成本高；
4. latch 争用明显。

17.5 AHI 观测

SHOW GLOBAL STATUS LIKE 'Innodb_hash%';

重点：

若哈希搜索比例不高但争用高，可评估关闭：

SET GLOBAL innodb_adaptive_hash_index=OFF;

变更要逐项观测，不能盲目跟从网上建议。

17.6 源码入口

断点：

b ibuf_insert
b btr_search_guess_on_hash

17.7 判断方法

问题：二级索引写入慢
  -> buffer hit rate
  -> ibuf merge status
  -> index cardinality
  -> whether unique

问题：等值查询 CPU 高
  -> AHI searches
  -> mutex waits
  -> page access pattern

本章小结

Change Buffer 用延迟合并降低冷二级索引写入 IO，AHI 用哈希降低热点页定位成本。二者都依赖访问模式，必须结合状态指标和 latch 争用判断收益。

思考题

1. 为什么唯一索引不能直接使用 Change Buffer？
2. Change Buffer merge 何时发生？
3. AHI 对范围查询为什么收益有限？
4. 如何判断 AHI 是否引发争用？
5. 内存充足时 Change Buffer 是否一定有收益？