Mysql索引数据结构

首先，数据库索引使用树来存储，因为树的查询效率高，而且二叉查找树还可以保持数据的有序。

那么索引为什么没有使用二叉树来实现呢？

其实从算法逻辑上讲，二叉查找树的查找速度和比较次数都是最小的，但是从Mysql的角度讲，我们不得不考虑一个现实问题：磁盘IO。

查找都是索引操作，一般来说索引非常大，尤其是关系型数据库这种，当数据量比较大的时候，索引的大小有可能几个G甚至更多，数据量大的索引能达到亿级别，所以为了减少内存的占用，数据库索引是存储在外部磁盘上的。

当我们利用索引查询的时候，不可能把整个索引全部加载到内存，只能逐一加载每个磁盘页，磁盘页对应索引树的节点。

那么Mysql衡量查询效率的标准就是磁盘IO次数。

如果我们利用二叉树作为索引结构，那么磁盘的IO次数和索引树的高度是相关的。

那么为了提高查询效率，就需要减少磁盘IO数。为了减少磁盘IO的次数，就需要尽量降低树的高度，需要把原来“瘦高”的树结构变的“矮胖”，树的每层的分叉越多越好，因此B树正好符合我们的要求，这也是B-树的特征之一。

原来的二叉树一个节点只存储一个数据，要想把它变“矮胖”，就需要在一个节点存储多个数据，同时为了查找必须保持节点结构的有序，这样B树就应运而生了。

B-树（B类树）的特点就是每层节点数目非常多，层数很少，目的就是为了就少磁盘IO次数。

B-树是一种多路平衡查找树，它的每一个节点最多包含K个孩子，k称为B树的阶。k的大小取决于磁盘页的大小。

一个m阶的B树具有如下几个特征：

1.根结点至少有两个子女。

2.每个中间节点都包含k-1个元素和k个孩子，其中 m/2 <= k <= m。

3.每一个叶子节点都包含k-1个元素，其中 m/2 <= k <= m。

4.所有的叶子结点都位于同一层。

5.每个节点中的元素从小到大排列，节点当中k-1个元素正好是k个孩子包含的元素的值域分划。

一个B树结构的具体例子。

在B-树中进行查询时，在查询的中的比较次数其实不比二叉查找树少，尤其当单一节点中的元素数量很多时。

可是相比磁盘IO的速度，内存中的耗时几乎可以忽略，所以只要树的高度足够低，IO次数足够少，就可以提高查询性能。

相比之下节点内部元素多一点也没有关系，仅仅是多了几次内存交互，只要不超过磁盘页的大小即可。这就是B-树的优势之一。

B树在插入和删除节点的时候如果导致树不平衡，就通过自动调整节点的位置来保持树的自平衡。

非关系型数据库MongoDB使用B树作为数据库索引。

大部分关系型数据库，比如Mysql，则使用B+树作为索引。

B+树是基于B-树的一种变体，有着比B-树更高的查询性能。

B+树和B-树有一些共同点，但是B+树也具备一些新的特征。

一个m阶的B+树具有如下几个特征：

1.有k个子树的中间节点包含有k个元素（B树中是k-1个元素），每个元素不保存数据，只用来索引，所有数据都保存在叶子节点。

2.所有的叶子结点中包含了全部元素的信息，及指向含这些元素记录的指针，且叶子结点本身依关键字的大小自小而大顺序链接。

3.所有的中间节点元素都同时存在于子节点，在子节点元素中是最大（或最小）元素。

一个B+树结构的具体例子。

从B+树的结构可以看出，B+树中的节点之间不但含有重复元素，而且叶子节点还用指针连在一起。

在B+树中，每一个父节点的中的元素都出现在子节点中，是子节点的最大（或最小元素）。

由于父节点的所有元素都出现在子节点，因此所有叶子节点包含了全量元素信息。

并且每个叶子节点都有指向下一个叶子节点的指针，形成了有序链表。

在B+树中，只有叶子节点才真正存储数据，非叶子节点不存储数据。

使用B+树做索引的好处主要体现在查询性能上。

在单元素查询的时候，B+树会自顶向下逐层查找节点，最终找到匹配的叶子节点。

对于范围查询，比如查询范围为3~11的元素，B-树只能依靠繁琐的中序遍历，首先自顶向下查找范围的下限，然后中序遍历找到上限。

B+树的范围查询则要简单的多，首先自顶向下查找范围的下限，然后只需要在叶子节点所在的链表上做遍历即可。

B+树和B-树的区别： 

B+树中间节点没有存储数据，只有叶节点存放数据，其余节点用来索引，所以同样大小的磁盘页可以容纳更多的节点元素，而B-树是每个索引节点都会有Data域。这就意味着，数据量相同的情况下，B+树的结构比B-树更加“矮胖”，因此查询是IO次数也更少。这就决定了B+树更适合用来存储外部数据，也就是所谓的磁盘数据。

其次，B+树的查询必须最终查询到叶子节点，而B-树只要找到匹配元素即可，无论匹配元素处于中间节点还是叶子节点。

因此，B-树的查询性能并不稳定（最好情况是只查根节点，最坏情况是查到叶子节点）。而B+树每一次查找都是稳定的。

综合起来，B+树相比B-树的优势有三个：

1.单一节点存储更多的元素，使得查询的IO次数更少。

2.所有查询都要查找到叶子节点，查询性能稳定。

3.所有叶子节点形成有序链表，便于范围查询。

最后总结一下：

数据库索引为什么不用AVL（平衡二叉树）？

数据库索引是存储在磁盘上，磁盘IO操作比较耗时，为了提高查询效率就需要减少磁盘IO的次数。而磁盘IO次数和树的高度有关，所以为了减少磁盘IO就需要降低树的高度，这是查找的结构就可以把二叉树变成B类的树。

数据库索引为什么用B+树而不用B-树？

数据库索引采用B+树的主要原因是B树在提高了磁盘IO性能的同时并没有解决元素遍历的效率低下的问题。正是为了解决这个问题，B+树应运而生。B+树只要遍历叶子节点就可以实现整棵树的遍历。而且在数据库中基于范围的查询是非常频繁的，而B树不支持这样的操作（或者说效率太低）。

那么MongoDB为什么使用B-树而不是B+树？

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

总体来说，Mysql选用B+树和MongoDB选用B-树还是以自己的需求来选择的。

数据库索引为什么不用红黑树？

首先看一下红黑树的特点：

红黑树是一种自平衡的二叉查找树，除了符合二叉查找树的基本特征外，它还具有下列的附加特征。

1.节点是红色或黑色。

2.根节点是黑色。

3.每个叶子节点都是黑色的空节点（NIL节点）。

4 每个红色节点的两个子节点都是黑色。(从每个叶子到根的所有路径上不能有两个连续的红色节点)

5.从任一节点到其每个叶子的所有路径都包含相同数目的黑色节点。

下图中这棵树，就是一颗典型的红黑树：

这是因为这些规则限制，才保证了红黑树的自平衡。红黑树从根到叶子的最长路径不会超过最短路径的2倍。

当插入或删除节点的时候，红黑树的规则可能被打破。这时候就需要做出一些调整， 来继续维持我们的规则。

那么在大规模数据存储的时候，红黑树往往出现由于树的深度过大而造成磁盘IO读写过于频繁，进而导致效率低下的情况。磁盘查找存取的次数往往由树的高度所决定，所以，只要我们通过某种较好的树结构尽量减少树的高度，就可以提高查询性能。B树可以有多个子女，从几十到上千，可以降低树的高度。

归结起来，使用B+树而不是用其他结构的原因就是为了减少磁盘IO的次数，减少数的高度，而B+树就很好的做到了这一点。

那么什么情况下使用红黑树?红黑树和B树使用场合有什么不同？

两者都是有序的数据结构，可用作数据容器。

红黑树多用在内部排序，即全放在内存中的，微软STL的map和set的内部实现就是红黑树。
B树多用在内存里放不下，大部分数据存储在外存上时。因为B树层数少，因此可以确保每次操作，读取磁盘的次数尽可能的少。

在数据较小，可以完全放到内存中时，红黑树的时间复杂度比B树低。
反之，数据量较大，外存中占主要部分时，B树因其读磁盘次数少，而具有更快的速度。

参考：（1）程序员小灰--《什么是B-树？》

           （2）程序员小灰--《什么是B+树？》   

           （3）https://blog.csdn.net/ligupeng7929/article/details/79529072

           （4）https://bbs.csdn.net/wap/topics/250015323