AHI命中率≈hash_searches/(hash_searches+hash_searches_btree)，需结合负载场景判断：>95%说明高效，70%–95%属正常，
自适应哈希索引（Adaptive Hash Index, AHI）是 InnoDB 存储引擎的一项优化机制，它在运行时自动为频繁访问的索引页建立哈希索引，以加速等值查询（如 WHERE col = ?）。但 AHI 不是总启用、也不总是有效——它的实际价值取决于工作负载特征，而命中率是最直观的衡量指标。
如何查看 AHI 当前命中率
InnoDB 通过 INFORMATION_SCHEMA.INNODB_METRICS 暴露 AHI 统计数据。关键指标有三个：
- hash_searches：使用 AHI 成功完成的查找次数
- hash_searches_btree：AHI 查找失败后回退到 B+ 树查找的次数
- hash_table_size：当前哈希表占用的 slot 数量（反映内存开销）
命中率 ≈ hash_searches / (hash_searches + hash_searches_btree)。建议用如下 SQL 实时计算：
SELECT ROUND(100 * i1.COUNT / (i1.COUNT + i2.COUNT), 2) AS `AHI_Hit_Ratio_%`, i1.COUNT AS `hash_searches`, i2.COUNT AS `hash_searches_btree` FROM INFORMATION_SCHEMA.INNODB_METRICS i1 JOIN INFORMATION_SCHEMA.INNODB_METRICS i2 ON i1.NAME = 'hash_searches' AND i2.NAME = 'hash_searches_btree';
AHI 命中率高低说明什么
命中率本身不能单独判断好坏，需结合场景解读：
- 高于 95%：说明 AHI 高效服务于当前负载，尤其是大量主键/唯一键等值查询，且数据局部性好（热点页反复访问）
- 70%–95%：属正常范围，AHI 有一定收益，但部分查询仍需走 B+ 树，可能因索引区分度低、查询条件不匹配哈希构建规则（如范围查询、LIKE 前缀模糊）
- 低于 50%：AHI 效益微弱，甚至可能成为负担。常见原因包括：频繁 DML 导致哈希表频繁重建、查询多为范围扫描或非等值条件、并发更新冲突引发哈希锁争用
影响 AHI 命中率的关键因素
AHI 并非对所有索引都生效，其行为受以下限制：
- 仅对B+ 树二级索引的叶节点页（含主键聚簇索引）自动构建哈希映射，且仅针对整行记录的完整索引键（不支持前缀索引哈希）
- 只加速 =、IN（单值）、IS NULL 类等值查找；
>、BETWEEN、LIKE 'abc%'等均无法命中 AHI - 若某索引页被频繁修改（INSERT/UPDATE/DELETE），InnoDB 可能禁用该页的 AHI，避免哈希一致性维护开销
- AHI 内存上限由
innodb_adaptive_hash_index_parts和总缓冲池大小共同决定，默认最多占用缓冲池约 1/8 内存
是否需要关闭 AHI？怎么调优
默认开启 AHI 通常是合理的，但高并发写入或 OLAP 类混合负载下可评估关闭：
- 临时关闭：
SET GLOBAL innodb_adaptive_hash_index = OFF;（重启失效） - 永久关闭：配置文件中设置
innodb_adaptive_hash_index = OFF - 不建议盲目调大哈希分区数（
innodb_adaptive_hash_index_parts），除非观察到hash_table_size持续接近上限且命中率未饱和 - 更有效的优化方向是：确保高频等值查询走的是，减少全表扫描和非等值条件，控制单事务修改热点页数量
