MySQL 中 InnoDB
实际只用 B+ 树，哈希索引是自动生成的辅助结构
别被“哈希索引”这个词误导：
InnoDB存储引擎**不支持用户手动创建哈希索引**，也没有
INDEX USING HASH语法。所谓“哈希索引”，仅指其内部为加速等值查询，在
B+ 树的基础上对**热点页内数据**做的自适应哈希索引（Adaptive Hash Index, AHI），完全由 MySQL 自动管理。
这意味着你无法控制它的存在、大小或字段；它只是 B+ 树的一个缓存加速层，不是独立索引类型。
AHI 只对单列等值查询（=）、且满足“连续访问同一页面多次”条件时才可能触发 范围查询（
BETWEEN、
>）、
ORDER BY、
LIKE 'abc%'等全部走 B+ 树，AHI 不生效 可通过
SHOW ENGINE INNODB STATUS查看 AHI 使用统计，但不能开关（
innodb_adaptive_hash_index是全局开关，生产环境一般保持开启）
MEMORY
引擎才真正支持用户定义的哈希索引
如果你真想对比“B+ 树 vs 哈希索引”的原始性能，得换存储引擎：只有
MEMORY（以前叫
HEAP）允许你显式声明
USING HASH：
CREATE TABLE t_hash ( id INT PRIMARY KEY, name VARCHAR(50) ) ENGINE=MEMORY INDEX idx_name USING HASH (name);
但注意：
MEMORY表数据全在内存，重启即丢，且不支持事务、外键、TEXT/BLOB 类型——它只适合临时缓存或只读字典表。 哈希索引只支持等值查询（
=、），
>、
IN（非单值）、
ORDER BY全部失效 哈希冲突会导致链表查找，最坏退化为 O(n)；而 B+ 树稳定在 O(log n)，且页内有序，利于范围扫描 哈希索引无法利用最左前缀原则：
(a,b)联合索引上查
WHERE a = ?，B+ 树能用，哈希索引不能
真实性能差异取决于查询模式，不是“谁更快”的简单结论
在
InnoDB场景下谈“B+ 树 vs 哈希索引”性能，本质是在问：“AHI 加速是否生效” + “B+ 树本身效率如何”。实际表现差异往往来自这些细节： 高并发单点查询（如用户登录校验
WHERE user_id = ?）：AHI 命中后可省去树遍历，延迟降低 10%–30%，但前提是该页已热、且无锁争用 批量等值查询（
WHERE id IN (1,2,3,...)）：B+ 树能复用叶子节点顺序读，而 AHI 是离散 hash 查找，反而可能更慢 写密集场景：AHI 构建/维护有额外开销，大量更新可能让 AHI 成为瓶颈（可通过
innodb_adaptive_hash_index_parts分片缓解） 内存不足时：AHI 占用 buffer pool 空间，挤占真正的数据页缓存，反而拖慢整体性能
别为哈希索引做优化，优先调好 B+ 树索引设计
真正影响性能的从来不是“B+ 树还是哈希”，而是你有没有建对索引、覆盖查询、避免回表、控制索引长度。比如：
联合索引顺序是否匹配查询条件（WHERE a = ? AND b > ? ORDER BY c→ 建
(a,b,c)） 字符串字段是否加了过长前缀（
VARCHAR(255)上建
INDEX(name(255))会浪费空间、拖慢插入） 是否误用函数导致索引失效（
WHERE YEAR(create_time) = 2024→ 改成
WHERE create_time >= '2024-01-01' AND create_time ）
AHI 是黑盒，B+ 树才是你可控的杠杆。把精力放在 explain 执行计划、慢日志分析、索引基数评估上，比纠结哈希更有回报。
