自适应哈希索引（ahi）是innodb自动管理的内存结构，不支持为存储过程单独配置，仅全局开关innodb_adaptive_hash_index控制，作用于高频等值访问的b+树索引页，与sql语句类型无关。
innodb_adaptive_hash_index 是 InnoDB 存储引擎的内部优化机制，它不支持为存储过程单独配置。自适应哈希索引（AHI）作用于 B+Tree 索引页的访问模式，与 SQL 语句类型（SELECT/UPDATE/存储过程）无关，只取决于底层索引页是否被高频、重复地访问。
innodb_adaptive_hash_index 参数控制的是全局行为
- 它是 Server 层的动态系统变量，影响所有使用 InnoDB 表的查询（包括存储过程中执行的
SELECT、UPDATE等） - 开启后，InnoDB 自动监控索引页访问频率，对热点页构建哈希索引，加速等值查找（如
WHERE id = ?） - 不区分语句来源：无论是客户端直连执行，还是通过存储过程调用，只要底层访问了相同索引页且频率达标，AHI 就可能被触发
常见误解是“给存储过程加 AHI”，实际无法做到。真正能影响 AHI 生效的是：
- 表是否使用 InnoDB 引擎
- 查询是否命中已有 B+Tree 索引（AHI 是 B+Tree 的补充，不是替代）
- 访问模式是否满足“单页高频等值查询”（例如主键或唯一索引上的循环查）
如何确认 AHI 是否在存储过程中起作用
运行存储过程前后，检查状态变量变化：
SHOW STATUS LIKE 'Innodb_buffer_pool_read%'; SHOW STATUS LIKE 'Innodb_adaptive_hash_searches%';
重点关注：
-
Innodb_adaptive_hash_searches：AHI 成功命中的次数 -
Innodb_adaptive_hash_searches_bypassed：因冲突/竞争被跳过的次数 -
Innodb_buffer_pool_read_requests：总逻辑读请求
如果存储过程反复执行相同主键查询，且 Innodb_adaptive_hash_searches 明显增长，说明 AHI 已介入。
容易踩的坑
- 存储过程中用了
LIKE '%abc'或函数索引（如UPPER(name)），AHI 不会生效 —— 它只加速 B+Tree 上的等值匹配路径 - 表数据量小、Buffer Pool 充足时，AHI 效果几乎不可测；它主要在高并发、大表、热点页争用明显时体现价值
- 启用 AHI 可能增加内存开销和 latch 竞争，在 OLTP 写多读少场景下反而降低性能
- MySQL 8.0.23+ 默认启用，但某些云厂商 RDS（如阿里云 PolarDB）可能默认关闭，需手动确认：
SELECT @@innodb_adaptive_hash_index;
AHI 是 InnoDB 自动决策的底层机制，你无法指定“让某个存储过程启用它”。真正可控的，是确保存储过程所查的字段有合适索引、避免全表扫描、减少锁等待 —— 这些才决定 AHI 有没有机会被触发。
