非聚集索引为何需要B-Tree？哈希索引难道不是更优选择？

你提到的哈希定位思路在静态、只读、仅需单值精确查找的场景下确实有直观优势，但数据库的实际运行场景要复杂得多，这也是B-Tree成为非聚集索引主流结构的核心原因：

1. 动态数据场景下的维护成本天差地别 #

你的例子基于固定1519行的静态数据，但数据库数据是持续插入、删除、更新的：

• 当数据量增长导致总页数增加时，你提到的行ID % 总页数映射规则会完全失效，所有行的哈希定位结果都需要重新计算，这在百万级、千万级数据量下是不可接受的全量操作；而B-Tree的节点分裂是渐进式的，仅涉及局部节点调整，不会全局失效。
• 哈希分布不均导致的页溢出，即便用拆分页解决，调整逻辑也远不如B-Tree的有序分裂简洁，还会产生大量数据碎片，长期下来会严重拖累IO性能。

2. 非聚集索引的多场景需求无法被哈希满足 #

数据库的非聚集索引不止用来做单值精确查找，还有大量高频场景是哈希方案无法高效支持的：

• 范围查询：比如查询id > 1000的所有行，哈希只能逐个计算行ID的哈希值定位，无法像B-Tree那样利用有序性直接遍历连续的节点区间；
• 排序/分组：基于非聚集索引的排序操作，B-Tree本身就是有序结构，可以直接输出有序结果，哈希则需要额外的全量排序步骤；
• 前缀匹配查询：比如字符串索引的LIKE 'abc%'，哈希完全无法处理这类前缀匹配，而B-Tree可以通过有序前缀快速定位。

3. 查询性能的稳定性差异 #

哈希查询的平均性能可能不错，但最坏情况（比如大量哈希冲突形成长链）下会退化到O(n)；而B-Tree的查询复杂度稳定在O(log n)，无论数据量多大，查找路径的长度都可控，这对于需要稳定性能的数据库系统来说至关重要。

补充：哈希索引的适用场景 #

当然，哈希索引也不是没用——在一些仅需单值精确查找、数据更新频率极低的场景（比如某些键值存储、特定业务的缓存索引），哈希索引确实有性能优势。但对于通用关系型数据库的非聚集索引来说，B-Tree的通用性、稳定性和对多场景的支持能力，远优于哈希方案。

内容的提问来源于stack exchange，提问作者user2967799