AHI能提升查询效率，是因为它将高频等值查询从B+树的2–3次页访问压缩为一次内存哈希查找；其生效需同时满足：纯等值匹配、相同模式连续访问≥100次（或≥页记录数/16）、该叶子页驻留在buffer pool中。
SELECT执行时InnoDB是否走AHI完全不可控
AHI不参与查询优化器决策，EXPLAIN永远看不到它，也不会出现在执行计划里。它只在B+树叶子页被高频访问后，由后台线程悄悄构建——后续相同模式的WHERE等值查询才可能命中。这意味着：你写SELECT * FROM user WHERE id = 123，第一次必然走B+树；第101次（或满足阈值）之后，才可能跳过根→非叶→叶的逐层遍历，直接哈希定位到页内记录偏移。
哪些SELECT能触发并受益于AHI
必须同时满足三个硬条件，缺一不可：
- 查询必须是纯等值匹配：
=或IN（如WHERE a = 1 AND b = 2），不能含LIKE、BETWEEN、函数包裹列（如WHERE YEAR(created) = 2024） - 同一索引页需被相同前缀模式连续访问 ≥100 次，或 ≥ 页内记录数 / 16（取大值）
- 该页当前必须驻留在
innodb_buffer_pool中，且是B+树叶子节点页（中间层页不建AHI）
典型有效场景包括：主键点查、二级索引等值查找、二级索引回表时的聚簇索引定位。而 JOIN 产生的临时结果集、ORDER BY 排序字段、GROUP BY 分组键，均不会触发AHI。
如何验证当前SELECT是否真的用了AHI
不能靠EXPLAIN，也不能看慢日志。唯一可靠方式是查性能计数器：
- 运行
SELECT * FROM INFORMATION_SCHEMA.INNODB_METRICS WHERE NAME IN ('adaptive_hash_searches', 'adaptive_hash_searches_bypass') -
adaptive_hash_searches增长说明AHI生效；若该值为0或长期不涨，说明没命中（可能是模式不满足，或AHI被禁用） - 对比
adaptive_hash_searches_bypass：该值高，说明大量查询本可走AHI却被绕过（常见于高并发争用哈希分区锁存器） - 注意：
SHOW ENGINE INNODB STATUS中的Hash table size只反映哈希槽数量，无法换算内存占用，也不代表某条SQL是否命中
innodb_adaptive_hash_index=ON时反而变慢的真相
开启AHI不是“只要开就快”，它会引入三类隐性开销：
- CPU监控成本：InnoDB需持续采样索引访问路径，高并发下这部分CPU消耗可能成为瓶颈
- 哈希分区争用：默认
innodb_adaptive_hash_index_parts=8，若大量短键等值查询集中打在同一分区，会卡在hash_lock上 - Buffer Pool挤占：AHI内存完全来自buffer pool，热点页越多、索引键越宽，实际可用缓存就越少，可能加剧页淘汰，反向拖慢其他查询
真正容易被忽略的是：AHI是“延迟生效+模式敏感”的隐式加速器。它不响应单次查询，只对稳定重复的访问模式建模；它不保证每次命中，只在页级热点形成且哈希桶未被锁住时才介入。调优时盯着 adaptive_hash_searches 和 adaptive_hash_searches_bypass 的比值，比盲目开关参数更有意义。
