为什么DB索引使用平衡树，而不是哈希表？

Question

在磁盘访问方面，Hashtables似乎更受欢迎。索引通常用树实现的真正原因是什么？ 对不起，如果它是婴儿，但我没有在SO上找到直接答案。

Answer 1

数据的一个常见操作是对其进行排序或搜索范围内的数据 - 树将按顺序包含数据，而哈希表仅用于查找行并且不知道下一行是什么排是。

由于这个answer

，哈希表对于这种常见情况并不好

SELECT * FROM MyTable WHERE Val BETWEEN 10000 AND 12000

或

SELECT * FROM MyTable ORDER BY x

显然，有些情况下哈希表更好，但最好先处理主要案例。

Answer 2

尺寸，btree开始小而且完美成型，并且很好地适应了巨大的尺寸。哈希具有固定的大小，对于您拥有的数据量，可能太大（10,000个条目可容纳10,000个条目）或太小（10,000个桶用于1,000,000,000个条目）。

Answer 3

哈希表对这种情况没有任何好处：

SELECT * FROM MyTable WHERE Val BETWEEN 10000 AND 12000

Answer 4

只需查看与MEMORY存储引擎相关联的MySQL's hash index implementation即可查看其缺点：

1. 它们可以与=等等运算符一起使用，但不能与<
等比较运算符一起使用
2. 优化器无法使用哈希索引来加速ORDER BY操作。
3. 只有整个键可用于搜索行。 （使用B树索引，密钥的任何最左前缀都可用于查找行。）
4. 优化程序无法确定两个值之间大约有多少行（范围优化程序使用它来决定使用哪个索引）。

请注意，上述内容适用于在内存中实现的哈希索引，而不考虑与磁盘上实现的索引相关的磁盘访问问题。 @silentbicycle指出的磁盘访问因素会使它更倾向于支持平衡树索引。

Answer 5

数据库通常使用B +树（特定类型的树），因为它们具有更好的磁盘访问属性 - 每个节点可以构成文件系统块的大小。尽可能少地执行磁盘读取会对速度产生更大的影响，因为花在追逐树中的指针或散列上的时间相对较少。

Answer 6

当数据没有增加时，Hasing是好的，当N / n是常数时，更加技术化。 其中N =元素数和n =散列槽..

如果不是这种情况，则哈希不会带来良好的性能提升。

在数据库中，数据很可能会增加很快的数据，因此使用哈希并不是一个好主意。

并且是排序也是......

Answer 7

“在数据库中，数据可能会增加很多，所以使用哈希并不是一个好主意。”

这是一个过分夸大的问题。是哈希空间必须固定大小（模数解决方案，可扩展哈希），是的，必须管理它们的大小，是的，有人必须做这个工作。

也就是说，如果你充分利用基于散列的物理位置，性能会提升，这是巨大的。