二叉树

 

如果数据都在内存中,我们就用平衡二叉查找树即可,这样效率最高。

在前面的文章中我使用过红黑树(大致平衡的二叉查找树),500万节点时,搜索的深度可以达到50,也就是需要50次指针操作才能获取到数据。

数据在内存中,50次间接寻址不是什么问题。

 

B树

但数据在硬盘中,50次间接寻址肯定就不行了,所以就必须减少树的深度。

于是我们的树就不是二叉了,而是多叉,举例来说,如果是10叉,500万节点时,log105000000 = 7,这样与log25000000=27的深度有了大大的减少,而在实际应用中,应该是远远大于10叉,分叉多了,硬盘的代价下来了,但CPU的负担就上来了,因为要进行更多次的比较,不过这不是什么问题,这个世界鱼与熊掌通常是不能兼得的。

 

B+树

假如我们有一张数据库表中有一列:name需要建一个索引

索引无非就像目录一样,如下:

name    ROWID

lucy,    111111

jim,     222222

如果需要找jim,我们直接到硬盘的22222位置去找即可

因为在B树中,某个节点可能在叶子节点中,也可能在内部节点中

如果我们使用B树,那么在内部节点中,我们也必须将jim和222222这两个信息都存在节点中

一个硬盘块的大小通常是4K,这样我们的一个硬盘块就存不了太多的节点

这时候B+树来了,B+树中,内部节点只包含关键字信息,而没有附加信息,附加信息在叶子节点中

因为B+树的内部节点中没有222222信息,只有jim这个key,所以在B+树中内部节点可以包含更多的节点,树的深度还可以进一步的减少。

但有人提出,这不是最重要的原因,主要原因如下:

"本文评论下第149楼,fanyy1991针对上文所说的两点,道:个人觉得这两个原因都不是主要原因。数据库索引采用B+树的主要原因是 B树在提高了磁盘IO性能的同时并没有解决元素遍历的效率低下的问题。正是为了解决这个问题,B+树应运而生。B+树只要遍历叶子节点就可以实现整棵树的遍历。而且在数据库中基于范围的查询是非常频繁的,而B树不支持这样的操作(或者说效率太低)。"

我觉得很有道理~

 

参考文献:

http://blog.csdn.net/v_july_v/article/details/6530142

http://blog.163.com/mageng11@126/blog/static/14080837420118285443947/