自适应哈希索引（ahi）专为加速b+树叶子页上的等值查询，将最后一步记录定位从o(log n)降为o(1)；它基于buffer pool热点页自动构建，只读、无持久化、不参与事务，生效需满足精确匹配、无函数、联合索引全左前缀等条件。
自适应哈希索引（AHI）到底在加速什么？
MySQL 的自适应哈希索引不是用户手动创建的索引，而是 InnoDB 在运行时，基于 Buffer Pool 中的热点页自动构建的哈希结构，专为「等值查询」加速。它只对满足特定访问模式的 B+ 树叶子页 生效——比如某条记录被反复用 WHERE id = ? 查询多次，InnoDB 就可能为该页的主键值建立哈希映射。
关键点在于：AHI 是「只读缓存层」，不参与事务、不写 redo log、不保证一致性；它只是把 B+ 树查找路径（根→非叶→叶）中最后一步「定位具体记录」从 O(log n) 降为 O(1)，前提是查询条件能精确命中已缓存的哈希键。
为什么不是所有等值查询都走 AHI？
AHI 的触发有硬性限制，常见不生效场景包括：
-
WHERE条件含函数或表达式，如WHERE ABS(id) = 100—— InnoDB 无法提取确定的哈希键 - 使用了联合索引但只用左前缀，如索引是
(a,b)，查询WHERE a = 1可能走 AHI，但WHERE b = 2绝对不走（B+ 树本身都扫不到叶子页） - 查询涉及范围操作，如
WHERE id BETWEEN 100 AND 200—— AHI 只服务单值查找 - Buffer Pool 中对应页被驱逐或重载，AHI 条目随之失效（无持久化）
你可以通过 SHOW ENGINE INNODB STATUS 查看 Hash table size 和 used cells，但注意这个统计滞后且不实时；更可靠的方式是观察 INFORMATION_SCHEMA.INNODB_METRICS 中的 innodb_hash_searches 和 innodb_hash_searches_btree 差值。
Buffer Pool 大小和 AHI 效果有什么关系？
AHI 的内存开销直接来自 Buffer Pool，不是额外分配——它复用页内空间存储哈希表元数据。所以：
- Buffer Pool 过小 → 热点页驻留时间短 → AHI 建了又删，基本无效
- Buffer Pool 过大（比如占物理内存 80%+）→ 操作系统换页压力上升 → 反而拖慢整体响应
- AHI 默认开启（
innodb_adaptive_hash_index = ON），但高并发 OLTP 下可能因哈希表锁争用（hash_lock）导致性能抖动；这时关闭它反而更稳
典型调优动作不是调 AHI 参数，而是先确保 innodb_buffer_pool_size 足够容纳活跃数据集（例如按 SELECT COUNT(*) FROM information_schema.INNODB_BUFFER_POOL_PAGES 估算实际热页占比）。
什么时候该关掉自适应哈希索引？
关 AHI 不是“优化”，而是规避其副作用。真实踩坑场景包括：
- 业务大量执行
SELECT ... FOR UPDATE或高频率INSERT ... ON DUPLICATE KEY UPDATE，且主键冲突率高 → AHI 哈希锁与行锁交织，引发Waiting for table metadata lock或长等待 - 监控发现
innodb_mutex_spin_waits显著高于innodb_mutex_os_waits→ 说明哈希锁自旋消耗严重 - 使用 MySQL 8.0.22+ 且启用了
innodb_deadlock_detect = OFF→ AHI 内部锁机制与死锁检测逻辑存在已知冲突（见 Bug #105472）
临时关闭只需执行 SET GLOBAL innodb_adaptive_hash_index = OFF；但要注意：该变量动态生效后，已有 AHI 条目会逐步清理，不会立即清空，且重启后恢复默认值。
AHI 是个安静的后台加速器，依赖数据访问局部性；它不解决索引缺失问题，也不替代合理的 EXPLAIN 分析。真正容易被忽略的是：你看到的「查询变快」，大概率是 Buffer Pool 命中 + AHI 双重作用，而非 AHI 单独功劳——别为了调 AHI 去动 Buffer Pool 配置。
