AHI不生效是因为它仅对高频访问的索引页自动构建哈希映射，而单次查询、无索引字段、前缀超长、缓冲池压力大等均会导致失效；需通过SHOW ENGINE INNODB STATUS和INNODB_METRICS运行时指标验证是否真正起效。
自适应哈希索引（AHI）不是你“启用就能用”的功能，它只在满足特定访问模式时自动生效；盲目依赖或强行开启反而可能增加内存争用和锁开销。
为什么SELECT * FROM user WHERE id = 10086没走AHI？
AHI不会为所有等值查询构建，它只对“被反复访问的索引页”建立哈希映射。常见失效原因包括：
- 单次查询或低频查询：AHI触发需要某索引前缀在短时间内被访问约 1/10 次（内部计数器阈值），冷数据或新连接几乎不可能触发
- 查询条件未命中已有B+树索引的叶子页：比如
WHERE name = 'alice'但name列没有索引，InnoDB连B+树都跳过，更不会建AHI - 索引前缀太长或含可变长度字段（如
VARCHAR(255)）：AHI最多使用前 307 字节，超长或高熵值会降低哈希命中率 - 缓冲池压力大：当
innodb_buffer_pool_pages_free过低，AHI构建会被抑制，避免挤占热页空间
innodb_adaptive_hash_index 开关的实际影响
该变量控制AHI整体开关，但它不是“开就加速、关就变慢”的简单开关：
- 设为
OFF会立即清空所有已构建的AHI哈希表，后续查询完全回退到B+树路径 - 设为
ON并不保证AHI立刻生效——它只是允许引擎在满足条件时自动构建，重建过程是异步且延迟的 - MySQL 8.0.22+ 支持动态修改：
SET GLOBAL innodb_adaptive_hash_index = OFF;，无需重启 - 高并发写入场景下（如订单流水表），AHI可能引发
hash index latch等待，此时关闭反而提升吞吐
如何确认AHI是否真的在帮你加速？
不能只看执行计划——EXPLAIN 完全不显示AHI参与情况。必须结合运行时指标判断：
- 查状态：
SHOW ENGINE INNODB STATUS\G，在ROW OPERATIONS部分找adaptive hash searches和adaptive hash search failures行，比值高说明有效 - 监控计数器：
SELECT NAME, COUNT FROM information_schema.INNODB_METRICS WHERE NAME LIKE '%adaptive%';，重点关注adaptive_hash_searches - 对比关启效果：在稳定负载下，分别记录
innodb_buffer_pool_read_requests（逻辑读）与innodb_buffer_pool_reads（物理读）比值变化，AHI有效时前者显著上升、后者相对平稳 - 注意陷阱：若
adaptive_hash_searches很高但adaptive_hash_searches_btree（回退B+树的次数）也高，说明哈希冲突严重或键分布不均，实际收益有限
AHI真正的复杂点在于它不可控——你无法指定“给哪张表哪个字段建哈希”，也无法预知它何时构建、何时失效。它只对长期稳定的热点点查友好，而现代业务中大量短生命周期查询、多条件组合或参数化程度高的SQL，往往根本触不到AHI的边界。
