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 持续接近上限且命中率未饱和
• 更有效的优化方向是：确保高频等值查询走的是，减少全表扫描和非等值条件，控制单事务修改热点页数量