绝大多数业务场景应默认用B+Tree索引，因哈希索引仅MEMORY和NDB引擎支持显式创建，且仅适用于纯等值查询；InnoDB不支持USING HASH，仅提供不可控的自适应哈希索引。
哈希索引只在特定存储引擎和查询模式下有效，绝大多数业务场景应默认用 B+Tree；盲目换哈希索引不仅无效，还可能让查询直接退化为全表扫描。
哪些存储引擎真正支持显式 HASH 索引
MySQL 中能让你在 CREATE INDEX 里明确写 USING HASH 的，只有两个引擎：
-
MEMORY（旧称HEAP）：建表时默认就是哈希索引，除非你显式指定USING BTREE -
NDB（MySQL Cluster）：支持PRIMARY KEY ... USING HASH，用于分布式键值定位
InnoDB 不接受 USING HASH 语法——你执行 CREATE INDEX idx ON t(a) USING HASH 会报错 ERROR 1064。它只提供隐式的自适应哈希索引（AHI），由引擎自动判断热点页生成，无法手动控制或观察。
HASH 索引只适用于纯等值查询且无排序需求的场景
一旦查询条件里出现以下任意一种，HASH 索引就完全失效：
-
WHERE a > 100或BETWEEN（不支持范围） -
ORDER BY a（哈希表无序，无法避免 filesort） -
WHERE a LIKE 'abc%'（前缀匹配需有序结构） -
WHERE a IN (1,2,3,4,5)虽然语法上是等值，但 InnoDB 的 AHI 不覆盖多值 IN；MEMORY表虽支持，但实际仍逐个哈希查找，不如 B+Tree 的范围跳查高效
典型误用：给用户登录表的 email 字段建 HASH 索引，以为能加速 SELECT * FROM users WHERE email = ?。但若后续加了 ORDER BY created_at 或要查 email LIKE '%@gmail.com'，这个索引就彻底作废，且无法复用。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
B+Tree 是通用解，哈希只是窄路优化
对比关键指标：
- 等值查询性能：
HASH平均 O(1)，B+Tree 是 O(log n) —— 但现代 SSD 下，3～4 层 B+Tree 查找与一次哈希计算耗时差距已缩至微秒级 - 内存开销：
HASH需预留空槽防冲突，空间利用率常低于 70%；B+Tree 页填充率通常 >90% - 写放大：
HASH插入冲突时需重哈希或链地址，MEMORY表在高并发写入时易锁表；B+Tree 页分裂可控，InnoDB 还有合并机制 - 统计信息依赖：B+Tree 支持
ANALYZE TABLE生成准确的基数估算，优化器能更好选执行计划；HASH索引无分布统计，优化器常误判为“低选择性”
真实案例：某订单状态表用 MEMORY + HASH 存临时会话 ID，QPS 上万时发现 SELECT COUNT(*) 变慢——因为哈希表不维护行数，每次都要遍历所有桶；换成 BTREE 后，COUNT(*) 直接走索引 size，耗时降 90%。
真正该考虑哈希的唯一信号
仅当同时满足以下全部条件时，才值得验证 HASH 是否有益：
- 数据存于
MEMORY表（非磁盘表），且生命周期短（如会话、缓存中间结果） - 查询 100% 是单字段等值，从不涉及
ORDER BY、GROUP BY、范围、模糊匹配 - 字段值高度离散（低哈希碰撞率），比如 UUID 或加密后的 token
- 已用
EXPLAIN确认当前 B+Tree 查询在该字段上仍存在明显 IO 或 CPU 瓶颈
否则，默认用 B+Tree。InnoDB 的聚簇特性、预读机制、缓冲池管理，都围绕 B+Tree 深度优化过；而哈希索引在 MySQL 生态里始终是边缘能力，文档少、监控弱、调优手段几乎为零——它不是“更快的选项”，而是“更受限的特例”。
