自适应哈希索引（AHI）仅对buffer pool中被频繁访问的B+树叶子页动态构建哈希项，加速等值查询最后一步定位至O(1)，但需满足完全匹配、页未驱逐等条件；其生效与否须通过SHOW ENGINE INNODB STATUS中的hash searches/s比值或performance_schema指标验证，且受锁竞争、DDL及buffer pool大小显著影响。
自适应哈希索引（AHI）不改变查询计划，也不出现在 EXPLAIN 中；它只在 B+ 树叶子页被反复等值访问后，悄悄加速「最后一步定位」——从 O(log n) 降为 O(1)，但前提是查询条件完全匹配、页未被驱逐、且走的是已缓存的叶子页。
查询走不走 AHI 取决于是否命中热点叶子页
AHI 不作用于索引结构本身，只对 buffer pool 中「被频繁访问的 B+ 树叶子页」生效。不是“有索引就能用 AHI”，而是“某页被连续等值查够次数 + 滞留够久 → InnoDB 自动建哈希项”。常见不触发场景：
-
WHERE id = ?查询确实走了主键索引，但对应叶子页刚被刷出 buffer pool → AHI 条目已失效 -
WHERE user_id = 'abc' COLLATE utf8mb4_unicode_ci→ 表达式或隐式转换导致无法提取确定哈希键 -
WHERE (a,b) = (1,2)是联合索引全匹配，但实际访问的是不同页上的相同键值 → 哈希键含页地址，跨页不共享 - 查询带
ORDER BY或LIMIT→ 即使是等值条件，InnoDB 可能跳过 AHI 查找路径（因需保证顺序语义）
怎么确认当前查询是否受益于 AHI
不能靠 EXPLAIN，也不能看 rows_examined（AHI 查找不计入扫描行数）。唯一靠谱方式是实时比对 InnoDB 状态：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 执行
SHOW ENGINE INNODB STATUS\G，滚动到INSERT BUFFER AND ADAPTIVE HASH INDEX小节 - 关注
hash searches/s和non-hash searches/s的比值：比值 > 0.5 说明 AHI 正在活跃参与 - 手动跑 10 轮相同
SELECT * FROM t WHERE pk = ?，再查一次 status —— 若hash searches/s明显跳升，说明该查询已上 AHI - 更细粒度可查
performance_schema.innodb_metrics：对比innodb_hash_searches与innodb_hash_searches_btree差值
AHI 对 DDL 和并发的影响常被低估
AHI 是运行时动态结构，不持久化，但它会参与锁竞争和内存争用：
- 每个 AHI 查找需获取
hash_lock（全局锁），高并发点查下可能成为瓶颈，尤其当innodb_adaptive_hash_index_parts还是默认 8 分区时 -
ALTER TABLE ... ALGORITHM=INPLACE期间，InnoDB 会临时禁用 AHI 构建，但已有 AHI 条目仍有效；而ALGORITHM=COPY会重建表，旧 AHI 全丢 - 大批量
INSERT/UPDATE会触发大量 AHI 重建和淘汰，加剧 buffer pool 压力，此时关掉 AHI（SET GLOBAL innodb_adaptive_hash_index = OFF）反而更稳 - AHI 内存来自 buffer pool 本身，不是额外分配；所以
innodb_buffer_pool_size过小 → 热页驻留时间短 → AHI 建了又删，基本白忙
真正关键的不是“开不开 AHI”，而是理解它只加速特定路径：单值等值、叶子页热、无表达式、无函数。线上调优优先确保 buffer pool 能稳住热页，比纠结 AHI 开关更实在。
