自适应哈希索引不能按表禁用，仅支持全局开关innodb_adaptive_hash_index；它基于缓冲池中高频访问的索引页动态构建哈希映射，与表或索引对象无关，且不支持SESSION级设置或SQL提示。
自适应哈希索引根本不能按表禁用
直接说结论：innodb_adaptive_hash_index 是全局开关，mysql 不支持在表级别启用或关闭自适应哈希索引（ahi）。它作用于整个 innodb 存储引擎，对所有表一视同仁——没有 alter table ... disable adaptive hash 这种语法，也没有表级提示（hint）或注释能绕过。
这是设计使然：AHI 不是对某张表建哈希结构，而是监控缓冲池中「被高频等值访问的索引页」，自动为这些页构建内存哈希映射。它依附于页（page），不是表（table）或索引（index）对象本身。
常见错误现象包括：在业务表上加了 /*+ NO_HASH_INDEX */ 注释、尝试用 SET SESSION innodb_adaptive_hash_index = OFF 期望只影响当前查询——这些都无效，innodb_adaptive_hash_index 只接受 GLOBAL 级别设置，且 SESSION 级别变量根本不存在。
真正能控制 AHI 的只有全局配置项
想关掉 AHI，唯一可靠方式是修改全局状态；想开，也一样。但要注意生效方式和副作用：
-
SET GLOBAL innodb_adaptive_hash_index = OFF可立即生效，无需重启，但仅对后续新连接起作用；已建立的连接不会“丢失”已有哈希条目，只是不再新增 - 更稳妥的做法是在配置文件
my.cnf中写死：innodb_adaptive_hash_index = OFF，然后重启 MySQL，确保所有连接统一行为 - 不能用
SET SESSION修改，执行会报错Variable 'innodb_adaptive_hash_index' is a GLOBAL variable and should be set with SET GLOBAL - 该变量动态修改后，可通过
SHOW VARIABLES LIKE 'innodb_adaptive_hash_index'验证是否已变为OFF
为什么有时关 AHI 反而提升性能？
关 AHI 不是“优化”，而是权衡。它在某些场景下反而拖慢系统：
- 高并发写入 + 频繁二级索引更新：AHI 重建哈希表会争抢
buf_pool_mutex，导致线程阻塞，SHOW ENGINE INNODB STATUS中可见大量waiting for buffer pool mutex - 查询模式高度分散（无明显热点）：哈希命中率极低，却持续消耗缓冲池内存（AHI 占用空间计入
innodb_buffer_pool_size），挤占真实数据页缓存 - 负载以范围查询（
BETWEEN）、排序（ORDER BY）、模糊匹配（LIKE 'abc%'）为主：AHI 完全不生效，纯属白占资源 - 监控依据：观察
SHOW STATUS LIKE 'Innodb_hash_%'，若Innodb_hash_searches与Innodb_hash_searches_full比值长期低于 0.3，说明哈希效率低下
容易忽略的关键细节
AHI 关闭后，不代表“哈希逻辑彻底消失”。InnoDB 内部仍保留少量哈希辅助结构（比如锁系统、字典缓存），但用户可感知的查询加速路径已切断。
更关键的是：AHI 和 innodb_buffer_pool_size 强耦合。即使 AHI 关闭，如果缓冲池太小（比如
最后提醒一句：innodb_hash_index_digits 这个变量在 MySQL 8.0.23+ 已被废弃，设了也没用；而老版本中它仅影响哈希桶数量，无法替代开关本身。真要调参，优先盯紧 innodb_adaptive_hash_index 和 innodb_buffer_pool_size 这两个。
