AHI并非对所有等值查询生效，因其仅对满足高频、稳定、精确匹配且页驻留缓冲池的B+树叶子页按需构建哈希映射，不支持范围、LIKE、JOIN临时页等场景；其开关控制全局启用，但开启后需额外CPU监控且高并发下易成争用点，内存完全来自buffer pool，验证须依赖INNODB_METRICS实时计数器而非EXPLAIN。
Adaptive Hash Index 能提升查询效率，是因为它把高频等值查询从 B+ 树的多层遍历（通常 2–3 次页访问）压缩成一次内存哈希查找 —— 本质是用空间换时间，在缓冲池内为热点页动态建“快捷方式”。
为什么不是所有等值查询都走 AHI？
AHI 不是对整张表或整个索引建哈希表，而是按页粒度、按访问模式“按需生成”。只有同时满足以下条件，InnoDB 才会为某一页构建哈希索引：
-
WHERE条件必须是稳定重复的等值匹配（如WHERE id = 123或WHERE a = 1 AND b = 2），不能混用不同前缀的查询 - 该页以相同模式被连续访问 ≥ 100 次，或访问次数 ≥ 页内记录数 / 16（取较大值）
- 该页当前在
innodb_buffer_pool中，且是叶子节点页（非中间层 B+ 树页）
这意味着：JOIN 中的临时结果页、LIKE '%abc'、范围查询（BETWEEN）、排序字段等，都不会触发 AHI。
innodb_adaptive_hash_index 开关的实际影响
这个参数控制 AHI 的全局开关，但它不是“开就一定快，关就一定慢”的简单逻辑：
- 开启时，InnoDB 需要额外 CPU 周期监控索引访问模式、维护哈希分区锁存器；高并发下可能成为争用点（尤其大量
JOIN或短键等值查询） - 关闭后，所有查询严格走 B+ 树，QPS 可能下降 20%–40%（实测主键点查场景），但 CPU 波动更平稳，大表
DROP时不会卡住 - MySQL 5.7+ 默认启用，且
innodb_adaptive_hash_index_parts默认为 8 —— 分区太少易争用，太多则内存碎片上升，不建议盲目调到 64+
AHI 占用的是谁的内存？
AHI 完全驻留在 innodb_buffer_pool 内部，不单独申请内存。它复用已有页帧的元数据区域构造哈希桶和指针，所以：
- 没有显式内存配额，但热点页越多、索引列越宽，AHI 占用的 buffer pool 有效容量就越高
- 当 buffer pool 接近满载时，AHI 可能加剧页淘汰压力，间接影响其他热数据命中率
-
SHOW ENGINE INNODB STATUS中的Hash table size行可看到当前哈希槽数量，但无法直接换算出字节数
EXPLAIN 看到它是否生效，也没法强制某条 SQL 使用它 —— 它只对符合模式的后续查询起效，且仅在页级热点形成后延迟生效。想验证效果，得靠 INFORMATION_SCHEMA.INNODB_METRICS 查 adaptive_hash_searches 和 adaptive_hash_searches_bypassed 这两个计数器对比。 
