自适应哈希索引仅对高频等值查询有效，依赖运行时热点识别，若查询不集中则不生成；真实OLTP中命中率常低于5%，需通过hash searches/s及INNODB_METRICS指标验证实际收益。
自适应哈希索引在海量数据下是否有效
它只对高频等值查询有加速作用，且完全依赖运行时热点识别——数据量再大，如果 WHERE id = ? 这类查询不集中、不重复，AHI 就不会生成，也起不了作用。真实 OLTP 场景中，AHI 命中率常低于 5%，大量内存被占用却无实际收益。
查看 AHI 实际使用情况的正确方式
别只看 SHOW ENGINE INNODB STATUS \G 输出里那几行 Hash table size，它们只反映内存分配大小，不说明是否真在用。关键要看：
-
0.00 hash searches/s：该值长期为 0 或极低（如 -
hash searches/s与non-hash searches/s的比值：理想情况下应 > 0.2 才算有实质性贡献 - 配合
INFORMATION_SCHEMA.INNODB_METRICS查adaptive_hash_searches和adaptive_hash_searches_btree累计值，做差值对比
调整 innodb_adaptive_hash_index_parts 的实际影响
这个参数不是“开得越大越快”，而是为缓解高并发下的内部锁争用。但它的代价很实在：
- 每个 part 都要独立维护哈希桶数组，内存开销线性增长；设为 64 时，AHI 占用缓冲池可能多出 3%~5%
- 仅当
SHOW ENGINE INNODB STATUS中出现大量waiting for adaptive hash latch类等待时，才值得调高 - 默认值 8 对大多数 32 核以下机器已足够；盲目设到 32 或 64，反而因 cache line false sharing 拖慢单核查询
关闭 AHI 的合理时机和操作
当你的负载以范围查询、ORDER BY、LIKE 'prefix%' 为主，或监控发现 hash searches/s 持续 ≈ 0，同时缓冲池压力较大（Buffer pool hit rate
- 动态关闭：
SET GLOBAL innodb_adaptive_hash_index = OFF;（立即生效，无需重启） - 配置文件持久化：
[mysqld]下加innodb_adaptive_hash_index = OFF - 注意：关闭后已有 AHI 内存会逐步释放，但不会立刻归零；观察
Hash table size行数值缓慢下降即可确认生效
EXPLAIN 也完全不体现。你优化慢查时，最容易忽略的就是它既没帮上忙，又悄悄吃掉了本可用于 Buffer Pool 的内存。 
