Mysql索引为何用B+树而不用B-树

先从数据结构的角度来看
　　咱们知道B-树和B+树最重要的一个区别就是B+树只有叶节点存放数据，其他节点用来索引，而B-树是每一个索引节点都会有Data域。
　　这就决定了B+树更适合用来存储外部数据，也就是所谓的磁盘数据。

从Mysql（Inoodb）的角度来看

　　B+树是用来充当索引的，通常来讲索引很是大，尤为是关系性数据库这种数据量大的索引能达到亿级别，因此为了减小内存的占用，索引也会被存储在磁盘上。
那么Mysql如何衡量查询效率呢？磁盘IO次数，B-树（B类树）的特定就是每层节点数目很是多，层数不多，目的就是为了就少磁盘IO次数，当查询数据的时候，最好的状况就是很快找到目标索引，而后读取数据，使用B+树就能很好的完成这个目的，可是B-树的每一个节点都有data域（指针），这无疑增大了节点大小，说白了增长了磁盘IO次数（磁盘IO一次读出的数据量大小是固定的，单个数据变大，每次读出的就少，IO次数增多，一次IO多耗时啊！），而B+树除了叶子节点其它节点并不存储数据，节点小，磁盘IO次数就少。这是优势之一。
　　另外一个优势是什么，B+树全部的Data域在叶子节点，通常来讲都会进行一个优化，就是将全部的叶子节点用指针串起来。这样遍历叶子节点就能得到所有数据，这样就能进行区间访问啦。
(数据库索引采用B+树的主要缘由是 B树在提升了磁盘IO性能的同时并无解决元素遍历的效率低下的问题。正是为了解决这个问题，B+树应运而生。B+树只要遍历叶子节点就能够实现整棵树的遍历。并且在数据库中基于范围的查询是很是频繁的，而B树不支持这样的操做（或者说效率过低）)

　　至于MongoDB为何使用B-树而不是B+树，能够从它的设计角度来考虑，它并非传统的关系性数据库，而是以Json格式做为存储的nosql，目的就是高性能，高可用，易扩展。首先它摆脱了关系模型，上面所述的优势2需求就没那么强烈了，其次Mysql因为使用B+树，数据都在叶节点上，每次查询都须要访问到叶节点，而MongoDB使用B-树，全部节点都有Data域，只要找到指定索引就能够进行访问，无疑单次查询平均快于Mysql（但侧面来看Mysql至少平均查询耗时差很少）。

整体来讲，Mysql选用B+树和MongoDB选用B-树仍是以本身的需求来选择的。

 

B树相对于红黑树的区别

　　在大规模数据存储的时候，红黑树每每出现因为树的深度过大而形成磁盘IO读写过于频繁，进而致使效率低下的状况。为何会出现这样的状况，咱们知道要获取磁盘上数据，必须先经过磁盘移动臂移动到数据所在的柱面，而后找到指定盘面，接着旋转盘面找到数据所在的磁道，最后对数据进行读写。磁盘IO代价主要花费在查找所需的柱面上，树的深度过大会形成磁盘IO频繁读写。根据磁盘查找存取的次数每每由树的高度所决定，因此，只要咱们经过某种较好的树结构减小树的结构尽可能减小树的高度，B树能够有多个子女，从几十到上千，能够下降树的高度。