MySQL 中，自适应哈希索引（Adaptive Hash Index，AHI） 是 InnoDB 存储引擎的一项内存级优化功能，核心是自动将热数据的索引页（B+树索引）缓存为哈希表，以加速等值查询（如 WHERE id = 100）。
1. 核心作用：用哈希表加速 B+树等值查询
-
InnoDB 默认使用 B+树作为索引结构，查询时需从根节点到叶子节点逐层遍历（时间复杂度 O(log n)）。
-
AHI 会识别频繁被等值查询访问的索引页，自动在内存中为这些页构建哈希表：
-
哈希表的 key：查询条件中的索引键值（如 id=100 的 100）。
-
哈希表的 value：该键值在 B+树叶子节点中的物理地址（直接定位数据，时间复杂度 O(1)）。
-
通过这种方式，后续对同一键值的等值查询可跳过 B+树遍历，直接通过哈希表定位数据，大幅提升查询速度。
2. “自适应”的体现：自动管理，无需人工干预
-
AHI 完全由 InnoDB 自动控制，无需用户配置或维护，核心“自适应”逻辑包括：
-
自动创建：当某索引页被等值查询访问的频率达到阈值（InnoDB 内部统计），自动为该页构建哈希表条目。
-
自动淘汰：当索引页的访问频率下降（不再是热数据），或内存紧张时，自动删除对应的哈希表条目，释放内存。
-
只缓存热数据：仅对高频访问的索引页生效，避免无意义的内存占用（哈希表本身存储在 InnoDB 缓冲池的“哈希索引区”）。
3. 适用场景与局限性
适用场景
-
仅优化 等值查询（如 =、IN），对范围查询（如 >, <, BETWEEN）完全无效（哈希表无法支持范围匹配）。
-
适合 读多写少、存在大量重复等值查询的业务（如电商商品详情查询、用户 ID 匹配等）。
局限性
-
不支持范围查询：这是哈希表的固有特性，AHI 无法优化 B+树擅长的范围查询场景。
-
内存开销：哈希表需占用 InnoDB 缓冲池内存，若热数据过多，可能挤压数据页缓存，反而影响性能（可通过参数 innodb_adaptive_hash_index_parts 控制分区，减少锁竞争）。
-
可能失效的情况：若表数据频繁更新（如大量 INSERT/UPDATE/DELETE），会导致哈希表频繁重建，优化效果减弱。
4. 关键配置（默认开启，按需调整）
-
开启/关闭 AHI：通过参数 innodb_adaptive_hash_index 控制（默认 ON，即开启）。
-
若业务以范围查询为主、或内存紧张，可手动关闭（设置为 OFF），避免内存浪费。
-
查看 AHI 状态：通过 SHOW ENGINE INNODB STATUS 命令，在“Adaptive Hash Index”部分查看哈希表的命中次数、条目数量等统计信息，判断优化效果。
结论
AHI 是 InnoDB 针对等值查询的“智能缓存”，无需人工干预即可提升热数据查询效率，但仅适用于特定场景，且需注意其对缓冲池内存的占用。
