Algorithm B树比AVL或红黑树快？

我知道性能从来不是黑白的，通常一个实现在X情况下更快，在Y情况下更慢，等等。但一般来说，B树比AVL或红黑树更快吗？它们的实现要比AVL树（甚至可能是红黑树）复杂得多，但它们是否更快（它们的复杂性是否有回报）

---

编辑：我还想补充一点，如果它们比同等的AVL/RedBlack树更快（就节点/内容而言）-为什么它们更快？

它们在不同的情况下使用-当树节点需要在存储中保持在一起时使用B-树-通常是因为存储是一个磁盘页，因此重新平衡可能非常昂贵。当您没有此约束时，将使用RB树。因此，如果要实现（比如）关系数据库索引，B树可能会更快，而RB树可能会更快地用于（比如）内存内搜索。

没有什么可以阻止只在内存中工作的B树实现。事实上，如果密钥比较便宜，内存中的B-Tree可以更快，因为它在一个节点中打包多个密钥将在搜索过程中导致更少的缓存未命中。有关性能比较，请参阅链接。引语：“速度测试结果很有趣，显示B+树对于包含16000个项目以上的树来说速度要快得多。”（B+树只是B-树的一个变体）。

肖恩的帖子（目前被接受的帖子）包含几个不正确的说法。对不起，肖恩，我不是故意粗鲁；我希望我能让你相信我的陈述是基于事实的

它们的用例完全不同，因此不可能进行比较

它们都用于维护一组具有快速查找、插入和删除功能的完全有序的项。它们具有相同的界面和相同的意图

RB树通常是用于提供对数据的快速访问（理想情况下是O（logN））的内存结构。[……]

始终为O（日志n）

B-树通常是基于磁盘的结构，因此固有地比内存中的数据慢

胡说八道。在磁盘上存储搜索树时，通常使用B树。这是事实。当您将数据存储在磁盘上时，访问速度比内存中的数据慢。但存储在磁盘上的红黑树也比存储在内存中的红黑树慢

你在比较苹果和桔子。真正有趣的是比较内存中的B树和内存中的红黑树

[顺便提一下：B树与红黑树相比，在I/O模型中理论上是有效的。我已经通过实验测试（并验证）了I/O模型的排序；我希望它也适用于B树。]

B-树很少是二叉树，一个节点可以拥有的子节点的数量通常很大

明确，B-树节点的大小范围是树的参数（C++中，你可能想要使用整型值作为模板参数）。 当数据发生变化时，B-树结构的管理可能相当复杂

我记得它们比红黑树更容易理解（和实现）

B-tree尽量减少磁盘访问次数，以便数据检索具有合理的确定性

这是事实

在一个非常复杂的数据库中查找一点数据所必需的4b-tree访问是很常见的

有数据吗

在大多数情况下，我会说内存中的RB树更快

有数据吗

因为查找是二进制的，所以很容易找到一些东西。B-tree每个节点可以有多个子节点，因此在每个节点上，您必须扫描节点以查找适当的子节点。这是一个O（N）操作

每个节点的大小是一个固定的参数，因此即使进行线性扫描，它也是O（1）。如果我们将oh设置为每个节点的大小，请注意，通常会对数组进行排序，使其为O（logn）

在RB树上，它应该是O（logN），因为您正在进行一次比较，然后进行分支

你在比较苹果和桔子。O（logn）是因为树的高度最多为O（logn），就像B树一样

此外，除非你在红黑树上玩一些讨厌的分配把戏，否则可以合理地推测B树有更好的缓存行为（它访问一个数组，而不是到处散落的指针，并且分配开销更少，增加内存位置），这可能有助于它在速度竞赛中发挥作用

我可以指出实验证据，B-树（特别是尺寸参数为32和64）在小尺寸方面与红黑树非常有竞争力，并且在n值中等偏大的情况下，其表现也优于传统的B-树。看

---

B-树更快。为什么？我猜想这是由于内存局部性、更好的缓存行为和更少的指针跟踪（如果不是相同的话，它们在某种程度上是重叠的）。

它们都具有相同的渐近行为，因此性能更多地取决于实现，而不是使用哪种类型的树。 树结构的某种组合实际上可能是最快的方法，其中B-树的每个节点都正好适合缓存线，并且使用某种二叉树在每个节点内进行搜索。自己管理节点的内存也可能使您能够获得更大的缓存位置，但代价很高

就我个人而言，我只是使用标准库中的任何东西来使用我正在使用的语言，因为要获得非常小的性能增益（如果有的话），需要做大量的工作

---

从理论上讲。。。RB树实际上与B树非常相似，因为它们模拟2-3-4树的行为。AA树是一种类似的结构，它模拟了2-3棵树。

事实上，维基百科有一篇很棒的文章显示，每个RB树都可以很容易地表示为B树。以下面的树为例：

现在只要公司