ahi不能通过配置直接加速等值查询，其生效完全由innodb运行时自动决定；即使设为on，也仅解除构建限制，是否真正构建取决于索引页访问频次、是否有有效b+树索引、前缀长度是否≤307字节等条件，冷数据或单次查询均无法触发。
它不能“配置”来加速等值查询——你只能开关它，是否生效完全由InnoDB runtime自动决定。
为什么SET GLOBAL innodb_adaptive_hash_index = ON不等于“加速生效”
AHI不是开关一开就立刻建哈希表的功能，而是引擎在运行中持续观察索引页访问模式后，对满足阈值的热点页（比如某主键页被反复查几十次/秒）才异步构建。即使设为ON，冷数据、单次查询、无索引字段、前缀过长（如VARCHAR(255)且实际值超307字节）都会导致AHI完全不触发。
- 执行
SET GLOBAL innodb_adaptive_hash_index = ON仅是解除构建限制，不保证任何哈希结构生成 - MySQL 8.0.22+支持动态修改，无需重启；但5.7需重启才生效
- 若
SHOW ENGINE INNODB STATUS\G中0.00 hash searches/s长期为0，说明AHI根本没参与查询
怎么确认AHI真正在帮你省B+树遍历
别信配置项，看实时指标：
- 运行
SHOW ENGINE INNODB STATUS\G，定位到ROW OPERATIONS部分，关注adaptive hash searches和adaptive hash search failures两行——前者每秒>10且远高于后者，才算有效 - 查计数器：
SELECT NAME, COUNT FROM INFORMATION_SCHEMA.INNODB_METRICS WHERE NAME IN ('adaptive_hash_searches', 'adaptive_hash_searches_btree');，若adaptive_hash_searches增长快、adaptive_hash_searches_btree增长慢，说明哈希命中率高 - 对比关启效果：关闭前后，监控
Innodb_buffer_pool_read_requests（逻辑读）与Innodb_buffer_pool_reads（物理读）比值——AHI有效时前者应显著上升，后者波动小
什么情况下该关掉innodb_adaptive_hash_index
它不是免费午餐，内存和锁开销真实存在：
- 负载以
ORDER BY、LIKE 'abc%'、范围查询为主 → 关闭：SET GLOBAL innodb_adaptive_hash_index = OFF;，释放内存并避免无效占用 - 监控发现
waiting for adaptive hash latch等待频繁 → 先尝试调高innodb_adaptive_hash_index_parts（如从默认8改为16），但仅限32核以上且确认争用场景；否则直接关 -
innodb_buffer_pool_pages_free持续偏低 +hash searches/s ≈ 0→ 关闭后Hash table size会缓慢下降，证明内存被回收
容易被忽略的硬限制和陷阱
AHI的“自适应”本质决定了它不可控、不可预测：
- 无法指定给哪张表、哪个字段、哪条SQL建哈希——你连干预入口都没有
-
EXPLAIN完全不显示AHI参与，你以为走了索引，实际可能还在B+树上跳三层 - 哈希冲突高时（
adaptive_hash_searches_btree也高），说明键分布不均或前缀熵值大，此时AHI反而拖慢查询 - 它只加速
WHERE col = ?类单值精确匹配，WHERE a=1 AND b=2（覆盖最左前缀）可以，WHERE b=2（跳过前导列）或WHERE a > 1绝对不行
