navicat 17 设计表界面不提供“自适应哈希索引”配置项，因其是 innodb 引擎自动管理的内存结构，非用户可创建或开关的索引类型，仅对已有 b+ 树索引的高频等值查询透明加速。
navicat 17 的设计表界面里根本不能配置“自适应哈希索引”——它不是用户可创建或开关的索引类型，而是 innodb 存储引擎内部自动管理的结构，对用户完全透明。
为什么设计表里找不到“自适应哈希索引”选项
自适应哈希索引（Adaptive Hash Index, AHI）是 InnoDB 在运行时根据访问模式**自动构建并维护**的内存结构，不对应任何 SQL CREATE INDEX 语句，也不出现在 SHOW CREATE TABLE 或 Navicat 的索引列表中。它只作用于 B+ 树索引已存在的等值查询场景（如 WHERE col = ?），且仅当某页被频繁访问时才触发生成。
- Navicat 的“设计表 → 索引”面板只管理用户显式定义的索引：B-tree（默认）、FULLTEXT、SPATIAL、UNIQUE 等
- 哈希索引（Hash Index）作为独立索引类型，仅在
MEMORY引擎表中支持，而 InnoDB 不允许手动创建哈希索引 - AHI 不可禁用/启用（除非全局关闭：
SET GLOBAL innodb_adaptive_hash_index = OFF），也不接受字段粒度控制
哪些操作会间接影响 AHI 的生效效果
AHI 是否起效，取决于底层 B+ 树索引的质量和查询模式，而非 Navicat 中的任何配置：
- 确保关联字段有合适的 B-tree 索引（例如
ON t1.a = t2.b，t2.b 必须有索引）——AHI 只能加速已有索引的等值查找 - 避免在 WHERE 条件中对索引列使用函数或隐式类型转换（如
WHERE YEAR(create_time) = 2024），这会让 AHI 失效 - 高并发下 AHI 可能因锁争用被临时抑制，此时调整
innodb_adaptive_hash_index_parts（默认8）可缓解 - 执行计划中看到
type: ref或type: eq_ref且Extra无警告，通常意味着 AHI 已参与加速
如何验证 AHI 是否实际工作
不能靠 Navicat 界面判断，需查 MySQL 状态变量：
- 运行
SHOW ENGINE INNODB STATUS\G，搜索 “adaptive hash index” 部分，看hash searches/s和non-hash searches/s的比值（比值越高说明 AHI 越活跃） - 监控
Innodb_hash_searches与Innodb_non_hash_searches状态变量的增长速度（SHOW GLOBAL STATUS LIKE 'Innodb_hash%'） - 注意：即使 AHI 关闭，只要 B+ 树索引存在，查询仍能执行——只是少了一层内存哈希跳转优化
真正需要干预的，是 B+ 树索引的设计质量；把精力放在 Navicat 里建好覆盖查询的联合索引、避免冗余索引、定期分析表统计信息，比纠结 AHI 更实在。
