【深刻学习MySQL】MySQL的索引结构为何使用B+树？

前言

在MySQL中，不管是Innodb仍是MyIsam，都使用了B+树做索引结构(这里不考虑hash等其余索引)。本文将从最普通的二叉查找树开始，逐步说明各类树解决的问题以及面临的新问题，从而说明MySQL为何选择B+树做为索引结构。

目录

1、二叉查找树(BST)：不平衡

2、平衡二叉树(AVL)：旋转耗时

3、红黑树：树过高

4、B树：为磁盘而生

5、B+树

6、感觉B+树的威力

7、总结

1、二叉查找树(BST)：不平衡

二叉查找树(BST，Binary Search Tree)，也叫二叉排序树，在二叉树的基础上须要知足：任意节点的左子树上全部节点值不大于根节点的值，任意节点的右子树上全部节点值不小于根节点的值。以下是一颗BST(图片来源)。

当须要快速查找时，将数据存储在BST是一种常见的选择，由于此时查询时间取决于树高，平均时间复杂度是O(lgn)。然而，BST可能长歪而变得不平衡，以下图所示(图片来源)，此时BST退化为链表，时间复杂度退化为O(n)。

为了解决这个问题，引入了平衡二叉树。

2、平衡二叉树(AVL)：旋转耗时

AVL树是严格的平衡二叉树，全部节点的左右子树高度差不能超过1；AVL树查找、插入和删除在平均和最坏状况下都是O(lgn)。

AVL实现平衡的关键在于旋转操做：插入和删除可能破坏二叉树的平衡，此时须要经过一次或屡次树旋转来从新平衡这个树。当插入数据时，最多只须要1次旋转(单旋转或双旋转)；可是当删除数据时，会致使树失衡，AVL须要维护从被删除节点到根节点这条路径上全部节点的平衡，旋转的量级为O(lgn)。

因为旋转的耗时，AVL树在删除数据时效率很低；在删除操做较多时，维护平衡所需的代价可能高于其带来的好处，所以AVL实际使用并不普遍。

3、红黑树：树过高

与AVL树相比，红黑树并不追求严格的平衡，而是大体的平衡：只是确保从根到叶子的最长的可能路径很少于最短的可能路径的两倍长。从实现来看，红黑树最大的特色是每一个节点都属于两种颜色(红色或黑色)之一，且节点颜色的划分须要知足特定的规则(具体规则略)。红黑树示例以下（图片来源）：

 

与AVL树相比，红黑树的查询效率会有所降低，这是由于树的平衡性变差，高度更高。但红黑树的删除效率大大提升了，由于红黑树同时引入了颜色，当插入或删除数据时，只须要进行O(1)次数的旋转以及变色就能保证基本的平衡，不须要像AVL树进行O(lgn)次数的旋转。总的来讲，红黑树的统计性能高于AVL。

所以，在实际应用中，AVL树的使用相对较少，而红黑树的使用很是普遍。例如，Java中的TreeMap使用红黑树存储排序键值对；Java8中的HashMap使用链表+红黑树解决哈希冲突问题(当冲突节点较少时，使用链表，当冲突节点较多时，使用红黑树)。

对于数据在内存中的状况（如上述的TreeMap和HashMap），红黑树的表现是很是优异的。可是对于数据在磁盘等辅助存储设备中的状况（如MySQL等数据库），红黑树并不擅长，由于红黑树长得仍是过高了。当数据在磁盘中时，磁盘IO会成为最大的性能瓶颈，设计的目标应该是尽可能减小IO次数；而树的高度越高，增删改查所须要的IO次数也越多，会严重影响性能。

4、B树：为磁盘而生

B树也称B-树(其中-不是减号)，是为磁盘等辅存设备设计的多路平衡查找树，与二叉树相比，B树的每一个非叶节点能够有多个子树。所以，当总节点数量相同时，B树的高度远远小于AVL树和红黑树(B树是一颗“矮胖子”)，磁盘IO次数大大减小。

定义B树最重要的概念是阶数(Order)，对于一颗m阶B树，须要知足如下条件：

• 每一个节点最多包含 m 个子节点。
• 若是根节点包含子节点，则至少包含 2 个子节点；除根节点外，每一个非叶节点至少包含 m/2 个子节点。
• 拥有 k 个子节点的非叶节点将包含 k - 1 条记录。
• 全部叶节点都在同一层中。

能够看出，B树的定义，主要是对非叶结点的子节点数量和记录数量的限制。

下图是一个3阶B树的例子（图片来源）：

 

B树的优点除了树高小，还有对访问局部性原理的利用。所谓局部性原理，是指当一个数据被使用时，其附近的数据有较大几率在短期内被使用。B树将键相近的数据存储在同一个节点，当访问其中某个数据时，数据库会将该整个节点读到缓存中；当它临近的数据紧接着被访问时，能够直接在缓存中读取，无需进行磁盘IO；换句话说，B树的缓存命中率更高。

B树在数据库中有一些应用，如mongodb的索引使用了B树结构。可是在不少数据库应用中，使用了是B树的变种B+树。

5、B+树

B+树也是多路平衡查找树，其与B树的区别主要在于：

• B树中每一个节点（包括叶节点和非叶节点）都存储真实的数据，B+树中只有叶子节点存储真实的数据，非叶节点只存储键。在MySQL中，这里所说的真实数据，多是行的所有数据（如Innodb的聚簇索引），也可能只是行的主键（如Innodb的辅助索引），或者是行所在的地址（如MyIsam的非聚簇索引）。
• B树中一条记录只会出现一次，不会重复出现，而B+树的键则可能重复重现——必定会在叶节点出现，也可能在非叶节点重复出现。
• B+树的叶节点之间经过双向链表连接。
• B树中的非叶节点，记录数比子节点个数少1；而B+树中记录数与子节点个数相同。

由此，B+树与B树相比，有如下优点：

• 更少的IO次数：B+树的非叶节点只包含键，而不包含真实数据，所以每一个节点存储的记录个数比B数多不少（即阶m更大），所以B+树的高度更低，访问时所须要的IO次数更少。此外，因为每一个节点存储的记录数更多，因此对访问局部性原理的利用更好，缓存命中率更高。
• 更适于范围查询：在B树中进行范围查询时，首先找到要查找的下限，而后对B树进行中序遍历，直到找到查找的上限；而B+树的范围查询，只须要对链表进行遍历便可。
• 更稳定的查询效率：B树的查询时间复杂度在1到树高之间(分别对应记录在根节点和叶节点)，而B+树的查询复杂度则稳定为树高，由于全部数据都在叶节点。

B+树也存在劣势：因为键会重复出现，所以会占用更多的空间。可是与带来的性能优点相比，空间劣势每每能够接受，所以B+树的在数据库中的使用比B树更加普遍。

6、感觉B+树的威力

前面说到，B树/B+树与红黑树等二叉树相比，最大的优点在于树高更小。实际上，对于Innodb的B+索引来讲，树的高度通常在2-4层。下面来进行一些具体的估算。

树的高度是由阶数决定的，阶数越大树越矮；而阶数的大小又取决于每一个节点能够存储多少条记录。Innodb中每一个节点使用一个页(page)，页的大小为16KB，其中元数据只占大约128字节左右(包括文件管理头信息、页面头信息等等)，大多数空间都用来存储数据。

• 对于非叶节点，记录只包含索引的键和指向下一层节点的指针。假设每一个非叶节点页面存储1000条记录，则每条记录大约占用16字节；当索引是整型或较短的字符串时，这个假设是合理的。延伸一下，咱们常常听到建议说索引列长度不该过大，缘由就在这里：索引列太长，每一个节点包含的记录数太少，会致使树过高，索引的效果会大打折扣，并且索引还会浪费更多的空间。
• 对于叶节点，记录包含了索引的键和值(值多是行的主键、一行完整数据等，具体见前文)，数据量更大。这里假设每一个叶节点页面存储100条记录(实际上，当索引为聚簇索引时，这个数字可能不足100；当索引为辅助索引时，这个数字可能远大于100；能够根据实际状况进行估算)。

对于一颗3层B+树，第一层(根节点)有1个页面，能够存储1000条记录；第二层有1000个页面，能够存储1000*1000条记录；第三层(叶节点)有1000*1000个页面，每一个页面能够存储100条记录，所以能够存储1000*1000*100条记录，即1亿条。而对于二叉树，存储1亿条记录则须要26层左右。

7、总结

最后，总结一下各类树解决的问题以及面临的新问题：

1)       二叉查找树(BST)：解决了排序的基本问题，可是因为没法保证平衡，可能退化为链表；

2)       平衡二叉树(AVL)：经过旋转解决了平衡的问题，可是旋转操做效率过低；

3)       红黑树：经过舍弃严格的平衡和引入红黑节点，解决了AVL旋转效率太低的问题，可是在磁盘等场景下，树仍然过高，IO次数太多；

4)       B树：经过将二叉树改成多路平衡查找树，解决了树太高的问题；

5)       B+树：在B树的基础上，将非叶节点改造为不存储数据的纯索引节点，进一步下降了树的高度；此外将叶节点使用指针链接成链表，范围查询更加高效。

参考文献

《MySQL技术内幕：InnoDB存储引擎》

《MySQL运维内参》

https://zhuanlan.zhihu.com/p/54102723

https://cloud.tencent.com/developer/article/1425604

https://blog.csdn.net/whoamiyang/article/details/51926985

https://www.jianshu.com/p/37436ed14cc6

https://blog.csdn.net/CrankZ/article/details/83301702

https://www.cnblogs.com/gaochundong/p/btree_and_bplustree.html

 

创做不易，若是文章对你有帮助，就点个赞、评个论呗~

创做不易，若是文章对你有帮助，就点个赞、评个论呗~

创做不易，若是文章对你有帮助，就点个赞、评个论呗~