AHI是否生效的唯一可靠方式是观察SHOW ENGINE INNODB STATUS中hash searches/s与non-hash searches/s的比值：若hash searches/s持续>0且明显高于后者（如比值>5），说明AHI正在命中；该统计需两次采样差分计算速率，不可直接依赖单次绝对值。
怎么看 SHOW ENGINE INNODB STATUS 里的 AHI 统计是否有效
直接看 hash searches/s 和 non-hash searches/s 的比值，是验证 AHI 是否起效的唯一可靠方式。其他任何指标（比如执行计划里有没有“Using index”、EXPLAIN 输出、慢日志里的扫描行数）都跟 AHI 无关——AHI 是引擎层透明加速，不改变 SQL 语义，也不出现在执行计划中。
关键点：
-
hash searches/s持续 > 0，且明显高于non-hash searches/s（比如比值 > 5），说明 AHI 正在被命中 - 两次
SHOW ENGINE INNODB STATUS\G之间间隔 10 秒，手动跑几轮相同等值查询（如SELECT * FROM users WHERE id = 123），如果hash searches累计值增长快于non-hash searches，就是 AHI 生效的直接证据 - 如果
hash searches/s长期为 0，即使查询很热，大概率是没满足构建条件：索引页未被连续多次等值访问、前缀长度超限、或该索引类型不支持（如全文索引、空间索引）
为什么 EXPLAIN 看不到 AHI，也不能用它判断
EXPLAIN 只反映优化器阶段决策，而 AHI 是执行器在真正读取数据时才可能触发的内存级加速路径。它不参与索引选择、不改变访问类型（type 字段仍是 const 或 ref），也不影响 key 或 rows 的估算值。
常见误解：
- 看到
type: const就以为用了 AHI → 错，const只表示主键/唯一索引等值匹配，B+ 树本身就能做到 - 执行时间变短就归功于 AHI → 不一定，可能是缓存预热、buffer pool 命中、甚至网络抖动改善
- 加了二级索引后
EXPLAIN显示Using index→ 这是覆盖索引，和 AHI 完全无关
哪些查询根本不会触发 AHI 构建
AHI 只对特定模式的等值访问自动构建，不是所有带 = 的查询都能激活它。
明确不触发的场景：
- 查询条件含函数或表达式，如
WHERE YEAR(create_time) = 2024或WHERE email LIKE 'a%'（LIKE前缀匹配不算纯等值） - 使用了非 B+ 树索引，如
FULLTEXT、SPATIAL、或 MEMORY 引擎的哈希索引 - 查询走的是联合索引但只用到部分前缀，且引擎判定前缀区分度低（如
INDEX (a, b)，只查WHERE a = ?，但a值重复极高） - 事务中开启了一致性读（
REPEATABLE READ），且查询涉及 MVCC 版本判断，AHI 查找会退回到 B+ 树遍历以保证可见性
监控 AHI 时最容易忽略的三个细节
AHI 的统计数字藏得深、更新有延迟、解读有前提，漏掉任一细节都会误判。
必须注意：
-
SHOW ENGINE INNODB STATUS输出中的 AHI 统计是自实例启动以来的累计值，不是实时速率；要算速率得自己做差分，不能只看单次输出的绝对值 - AHI 内存占用不计入
innodb_buffer_pool_size，但实际从 buffer pool 里划走——如果发现 buffer pool 命中率莫名下降，而hash searches/s很高，很可能就是 AHI 吃掉了可观内存 - 禁用 AHI 测试（
SET GLOBAL innodb_adaptive_hash_index = OFF）后，旧的哈希表不会立即清空，而是逐步失效；观察性能变化需等至少 30 秒以上，且要避开后台合并线程（ibuf merge）干扰
