EXPLAIN看不见AHI是设计使然，因其为执行阶段透明加速层，不参与优化器计划生成；需通过SHOW ENGINE INNODB STATUS中的hash searches/s、INNODB_METRICS中的adaptive_hash_searches等运行时指标验证是否生效。
EXPLAIN 看不见 AHI，这是设计使然
MySQL 的 EXPLAIN 不会显示自适应哈希索引（AHI）是否被使用。这不是 bug，而是 InnoDB 的底层机制决定的：AHI 是查询执行阶段的透明加速层，发生在 B+ 树遍历路径中，不参与优化器的计划生成。所以你在 EXPLAIN 输出里永远看不到 key 字段标出 “ahi_name” 或类似内容，也别指望 type 变成 hash。
常见误解是盯着 key 和 type 判断 AHI 是否生效——这完全无效。哪怕 AHI 正在高速服务某条 WHERE user_id = ? 查询，EXPLAIN 依然只显示它用了 PRIMARY 索引、type 是 const 或 eq_ref。
真正能间接验证 AHI 生效的指标
要确认 AHI 是否起作用，得绕过执行计划，看运行时行为和状态变量：
-
SHOW ENGINE INNODB STATUS\G中的INSERT BUFFER AND ADAPTIVE HASH INDEX段落，会显示adaptive hash index hash table size（当前哈希桶数量）、used cells（已用槽位）、node heap memory（链表节点内存占用）——非零即说明 AHI 已构建并活跃 - 状态变量
Innodb_adaptive_hash_searches：表示通过 AHI 成功完成的查找次数；Innodb_adaptive_hash_searches_saved：表示因使用 AHI 而避免的 B+ 树搜索次数。两者持续增长，且后者占前者比例较高（例如 >10%），是 AHI 发挥价值的强信号 - 对比关闭 AHI 前后的
SELECT ... WHERE col = ?延迟：用SET GLOBAL innodb_adaptive_hash_index = OFF;临时禁用（注意仅对新连接生效），再压测相同等值查询。若延迟明显上升（尤其在高并发简单点查场景），基本可反推此前 AHI 在起效
AHI 不工作的典型场景与排查点
AHI 不是万能加速器，以下情况它根本不会介入：
- 查询条件含范围操作（
>、BETWEEN、LIKE 'abc%'）或非等值判断（IS NULL、!=），AHI 只响应=和IN（且IN列表不能太长，一般 ≤ 32 项） - 索引前缀太长或字段类型不友好：比如对
VARCHAR(500)列建索引，但实际查询值长度波动大，InnoDB 可能只对前 307 字节建哈希前缀，而你的查询值恰好超出该前缀范围，就无法命中 - 缓冲池压力大或 AHI 内存受限：
innodb_adaptive_hash_index_parts默认为 8，若并发线程多、热点分散，各分区哈希表容易提前触发淘汰逻辑；同时innodb_buffer_pool_size过小会导致 AHI 所需内存空间不足，自动收缩 - 刚启动或冷数据：AHI 是“学习型”结构，需要等某个索引键被连续高频访问（内部计数器达阈值，约 16 次/1 秒窗口）才会构建。新上线服务或低频表，
Innodb_adaptive_hash_searches长期为 0 属正常
别把自定义哈希列和 AHI 混为一谈
有人在表里加 email_hash INT UNSIGNED 并建 B+ 树索引，然后写 WHERE email_hash = CRC32(?) AND email = ?——这是手动哈希优化，和 AHI 完全无关。AHI 不依赖任何用户定义列，也不改变 SQL 写法。你不需要、也不应该在应用层模拟 AHI 的逻辑。
真正容易被忽略的是：AHI 的存在会让某些“本应走索引却没走”的问题更隐蔽。比如某条 WHERE status = 'active' 查询始终慢，你检查 EXPLAIN 发现走了索引，就以为没问题；但其实因为 status 区分度极低（大量重复值），InnoDB 根本不会为它建 AHI，B+ 树扫描叶子页仍很重。这时候该考虑的是索引选择性，而不是怀疑 AHI 失效。
