AHI仅对稳定重复的等值查询生效，如主键点查、二级索引回表；需目标页在Buffer Pool中且被同模式访问≥100次或≥记录数/16，才构建哈希映射；不支持范围、排序、模糊查询。

innodb_adaptive_hash_index 在 MySQL 5.7 中默认开启，但它带来的性能提升不是固定百分比，而是高度依赖实际负载模式。实测中主键点查（如 WHERE id = ?）或二级索引等值回表（如 WHERE name = ?）场景下，QPS 可提升 20%–40%，前提是满足 AHI 的触发条件；否则它压根不生效。

哪些查询能真正用上 AHI？

AHI 不是“所有 = 都加速”，它只对符合页级热点模式的等值查询起效：

• 必须是稳定重复的等值模式，比如连续执行 WHERE a = 1 AND b = 2，不能一会儿 a=1、一会儿 a=2
• 目标页必须已在 innodb_buffer_pool 中，且是 B+ 树叶子页（中间层页不参与）
• 该页需被相同模式访问 ≥ 100 次，或 ≥ 记录数 / 16（取较大值），才会触发哈希映射构建
• JOIN 中的临时结果页、LIKE '%abc'、BETWEEN、ORDER BY 等一律不触发

为什么有时开着反而变慢？

AHI 是带开销的“自动优化器”，不是无代价加速：

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

• 开启后，InnoDB 每次索引查找都要额外做哈希桶定位 + 分区锁存器检查，高并发下易成 CPU 争用点
• innodb_adaptive_hash_index_parts 默认为 8，分区太少（如设为 1）会导致锁竞争加剧；设得太多（如 64）又增加内存碎片和管理开销
• AHI 内存完全来自 innodb_buffer_pool，buffer pool 接近满载时，AHI 会挤占真实数据页空间，间接拉低整体命中率
• 大表 DROP 或 ALTER TABLE 期间，AHI 清理逻辑可能卡住线程，表现为“卡在 DROP”

怎么确认 AHI 是否在起作用？

别看 EXPLAIN —— 它完全不显示 AHI。验证必须靠运行时指标：

• 执行 SHOW ENGINE INNODB STATUS\G，搜索 Hash table size 行，数值 > 0 表示有哈希槽已分配
• 查询 INFORMATION_SCHEMA.INNODB_METRICS 表，重点关注：ahi_queries_used（AHI 成功命中的查询数）、ahi_requests（AHI 查找总请求数）
• 对比开关前后同一压力下的 SELECT 延迟分布（特别是 p95/p99），而非平均值——AHI 主要改善尾部延迟
• 关闭 AHI 后若 innodb_buffer_pool_wait_free 显著下降，说明之前 AHI 加剧了页淘汰压力

真正容易被忽略的是：AHI 生效有延迟，且不可控。你无法指定某张表、某个字段、某条 SQL 走 AHI；它只在页热起来之后才悄悄建“快捷方式”，而这个过程对应用完全透明。调优时若只盯着配置开关，却不管 buffer pool 命中率、查询模式稳定性、CPU 争用情况，很容易误判效果。