Adaptive Hash Index

做的事：先查一下这个开关本机到底是开是关

代码SELECT @@innodb_adaptive_hash_index; -- 用存储过程循环20000次，反复点查同50个id CALL hot_lookup_test();

验证：意外发现，本机这个开关真实是关着的

实测 · 本机执行输出

@@innodb_adaptive_hash_index: 0   ← 真实是关闭状态

关闭状态下，20000次热点点查：
  耗时 153451 微秒（约153.5毫秒）
  adaptive_hash_searches: 0

本以为AHI默认是开着的，真实查出来本机是关闭状态——这可能是Homebrew打包时的配置选择，也可能是环境本身的历史设置，本文没有深挖这个具体原因，只是如实记录了这个意外的起点：接下来的对比，是"真实打开AHI前后"，而不是原计划里"AHI默认开着，关掉看看差多少"。

验证：真实打开AHI，第一遍几乎没变，第二遍才真实见效

实测 · 本机SET GLOBAL innodb_adaptive_hash_index=ON 之后

第1遍（刚打开，AHI正在真实建立）：
  耗时 152114 微秒（约152.1毫秒，几乎和关闭时一样）
  adaptive_hash_searches: 19866   ← 但真实已经在大量走AHI了

第2遍（AHI真实已经热了）：
  耗时 108593 微秒（约108.6毫秒，比关闭时快约29%）
  adaptive_hash_searches: 39866（这一遍又真实新增了约20000次）

第一遍打开AHI，adaptive_hash_searches真实已经涨了19866次，说明这一遍里几乎每次点查都真实用上了刚建立的哈希索引，但整体耗时几乎没有改善——建立AHI结构本身也要花费真实的CPU和内存开销，抵消了查询本身节省下来的时间。到了第二遍，AHI结构真实已经稳定，不再需要额外维护开销，耗时才真实降到108.6毫秒，比AHI关闭时快了约29%。有意思的是，adaptive_hash_pages_added和adaptive_hash_rows_added这两个更细粒度的计数器，本文测试全程真实都停留在0，没有像adaptive_hash_searches那样正常增长——这个不一致本文没有找到确切原因，如实记录下来，不强行给出一个没有验证过的解释。测试结束后，本文把这个开关恢复成了原来的关闭状态。

分步演示：从关闭到打开，AHI两遍测试的真实轨迹

每一步都是本文上面用真实存储过程压测跑出来的原始结果。

AHI的收益要等它真的热起来才看得到

这一步新验证的状态

本文用到的工具

本机 MySQL 26.7.0（InnoDB），存储过程循环20000次点查同一批50个id
SET GLOBAL innodb_adaptive_hash_index + information_schema.INNODB_METRICS里的adaptive_hash_*计数器
没有验证：adaptive_hash_pages_added/rows_added这两个计数器为何全程停留在0，没有找到确切原因

下一篇 · MYSQL / INNODB 67

Redo Log Checkpoint