直接回答：B+ 树索引适合等值、范围（>、<、BETWEEN）、排序（ORDER BY）、模糊前缀（LIKE 'abc%'）和最左前缀匹配，是通用默认选择；哈希索引只支持精确等值匹配（=、IN），但单次等值查找理论上 O(1)，更快，适合纯等值查询场景。

展开解析：哈希索引的局限决定了它的小众地位：

  • 哈希值无序，无法用于范围查询与排序。
  • 无法利用最左前缀，联合哈希索引必须全部列参与。
  • 哈希冲突需要链式处理，冲突多时性能退化。

MySQL 实际情况：InnoDB 不开放手动建哈希索引，但有自适应哈希索引（AHI）——对热点 B+ 树页自动在内存建哈希加速等值查询，无需干预；MEMORY 引擎默认支持 HASH 索引。Redis 这类内存 KV 的"哈希索引"又是另一回事。实践中绝大多数业务索引用 B+ 树即可，等值场景 B+ 树 3-4 次页查找也足够快，真正值得考虑哈希的场景很少。

追问方向：自适应哈希索引的监控与关闭场景、全文检索为何用倒排而非这两种。