二叉树
如果数据都在内存中，我们就用平衡二叉查找树即可，这样效率最高。
在前面的文章中我使用过红黑树（大致平衡的二叉查找树），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/