哈希索引仅原生支持于MEMORY引擎，InnoDB中CREATE INDEX ... USING HASH被静默忽略，实际仍建B+Tree索引；其自适应哈希索引（AHI）由引擎自动管理，不可控、不显式、仅加速高频等值查询，且不支持范围、排序、前缀匹配等操作。
哈希索引只在Memory引擎中显式可用，InnoDB不支持CREATE INDEX ... USING HASH
MySQL的Hash索引不是通用功能，它仅原生存在于MEMORY存储引擎中。你执行CREATE INDEX idx_name ON t1(col) USING HASH，只有当表使用ENGINE=MEMORY时才真正生效；换成InnoDB，语句虽能执行成功，但实际创建的仍是B+Tree索引——MySQL会静默忽略USING HASH子句。
InnoDB确实有“自适应哈希索引”（AHI），但它完全由引擎自动管理：仅对频繁访问的B+Tree页片段建立哈希映射，用户无法控制、不能指定字段、也不能关闭（除非设innodb_adaptive_hash_index=OFF）。这不是你主动建的索引，而是一种加速缓存机制。
-
SHOW INDEX FROM t1查不到 AHI，它不出现在元数据里 - AHI 仅适用于等值查询且模式高度重复的场景，比如主键或唯一键的高频点查
- 一旦查询条件稍有变化（如加了
OR、IS NULL、函数包装），AHI 就失效
B+树索引支持范围查询、排序、前缀匹配，Hash索引连WHERE col > 100都走不了
这是最常踩坑的地方：看到=就以为能用Hash，却忘了业务里真正高频的是BETWEEN、ORDER BY、LIKE 'abc%'这类操作。B+树叶子节点天然有序且双向链表连接，扫描age BETWEEN 25 AND 35只需定位起点、顺序遍历链表；Hash索引底层是散列表，键值打乱后毫无顺序可言，根本无法跳过无关桶。
-
WHERE name LIKE 'Li%'：B+树可利用最左前缀快速定位Li开头的叶子区间；Hash索引必须全表哈希再逐个比对，退化为全表扫描 -
ORDER BY create_time DESC LIMIT 10：B+树直接从最大叶子节点倒序取；Hash索引需先取出全部结果再内存排序 - 联合索引
(a,b,c)上查WHERE a = 1 AND b > 5：B+树能用上前两列；Hash索引对b > 5完全无感，只能靠a = 1过滤后回表判断
等值查询时Hash不一定更快，哈希碰撞会让O(1)变成O(n)
理论上的O(1)前提是哈希函数均匀、桶足够多、数据无冲突。现实中，当字段重复值多（比如status TINYINT只有0/1/2）、或数据量增长导致桶数不足时，多个键会落在同一桶内，形成链表。此时查询要遍历链表比对——和B+树查log₂N层节点相比，链表长度可能更长。
- 一个
status字段建Hash索引，90%记录都是status = 1，那几乎所有哈希值都挤在同一个桶里 -
MEMORY表默认哈希桶数由MAX_ROWS估算，若预估不准，桶太少，碰撞率飙升 - 没有
EXPLAIN能显示Hash索引是否命中，你只能靠SELECT COUNT(*)对比执行时间猜测
别被“B+树要查logN层”吓住，现代SSD+缓冲池让实际IO开销极小
很多人觉得B+树要从根到叶查3–4层就是“慢”，但InnoDB把非叶子节点全缓存在buffer pool里，真实IO通常只有1次——叶子节点所在的数据页读取。而Hash索引虽然逻辑跳转少，但MEMORY引擎数据全在内存，没磁盘IO压力，所以对比失真。真正关键的是：B+树结构稳定，无论数据分布如何，查找路径长度恒定；Hash索引性能抖动大，依赖数据特征和配置参数。
线上表几乎全是InnoDB，你真需要优化等值查询，优先考虑覆盖索引、前缀索引或调整innodb_buffer_pool_size，而不是幻想换Hash索引——它根本不在你的工具箱里。
