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 争用情况，很容易误判效果。
