确认AHI是否生效需观察SHOW ENGINE INNODB STATUS中的hash searches/s、non-hash searches/s等指标联动变化，或通过performance_schema监控btr_search_latch等待及READ_DISK/READ_BUFFER比例。
怎么确认某条查询是否用上了 AHI
不能靠 EXPLAIN，它完全不显示 AHI；也不能看慢日志里的 rows_examined，因为 AHI 查找不算“行扫描”。唯一可靠方式是观察运行时统计，重点盯两个指标的联动变化。
查 SHOW ENGINE INNODB STATUS\G 里哪几项
执行该命令后滚动到 INSERT BUFFER AND ADAPTIVE HASH INDEX 小节，重点关注：
-
hash searches/s：每秒通过 AHI 成功命中的次数 -
non-hash searches/s：每秒绕过 AHI、走原 B+ 树路径的次数 -
hash table size：当前哈希表占用的 bucket 数量（反映构建规模） -
using for hash searches后面的数字：表示当前有多少索引页被纳入 AHI 覆盖
注意：hash searches/s 高但 queries to hash table 很低，说明 AHI 建了但没被有效命中——大概率是查询条件用了范围（BETWEEN）、前导列缺失或字符集隐式转换导致键值不匹配。
实操验证：手动触发并观察 AHI 生效过程
在复现环境里跑固定等值查询，比对前后状态：
- 先执行一次
SHOW ENGINE INNODB STATUS\G记下初始hash searches/s - 连续执行 20–30 次相同语句，如
SELECT * FROM user WHERE id = 12345; - 再执行一次
SHOW ENGINE INNODB STATUS\G，对比hash searches/s是否有明显跳升（比如从 0 → 5+/s） - 若无变化，检查该
id对应的索引页是否长期驻留在 buffer pool 中（可用information_schema.INNODB_BUFFER_PAGE辅助判断）
用 performance_schema 监控更细粒度行为
MySQL 5.6+ 支持通过以下表观测 AHI 实际参与情况：
-
performance_schema.events_waits_summary_global_by_event_name中搜索wait/synch/mutex/innodb/btr_search_latch：高等待说明 AHI latch 争用严重，反而可能拖慢查询 -
performance_schema.table_io_waits_summary_by_table中对比同一表的READ_DISK和READ_BUFFER比例：AHI 有效时，READ_DISK应显著下降 - 注意：这些表默认可能关闭采集，需提前开启对应 instrument，如
UPDATE performance_schema.setup_instruments SET ENABLED = 'YES' WHERE NAME = 'wait/synch/mutex/innodb/btr_search_latch';
AHI 是运行时动态构建的，没有“开关即生效”的瞬间。它依赖真实访问模式积累 + buffer pool 页驻留稳定性，临时跑一两条 SQL 很难触发，容易误判为“没起作用”。
