MySQL B+tree 索引原理

原文：https://blog.csdn.net/u013235478/article/details/50625677

文章目录

1、二叉查找树
2、平衡二叉树（AVL Tree）

2.1、四种失去平衡的定义：
2.2、四种失去平衡对应的旋转方法

2.2.1 、LL的旋转
2.2.2 、RR的旋转
2.2.3、LR的旋转
2.2.4 、RL的旋转

3、平衡多路查找树（B-Tree）
4、B+Tree
5、其它

5.1、覆盖扫描

B+树索引是 B+树在数据库中的一种实现，是最常见也是数据库中使用最为频繁的一种索引。

B+树中的B代表平衡（balance），而不是二叉（binary），因为B+树是从最早的 平衡二叉树 演化而来的。

在讲B+树之前必须先了解 二叉查找树、平衡二叉树（AVL Tree）和 平衡多路查找树（B-Tree），而 B+树 即由这些树逐步优化而来。

1、二叉查找树

二叉树具有以下性质：左子树的键值小于根的键值，右子树的键值大于根的键值。

如下图所示就是一棵 二叉查找树:
在这里插入图片描述

对该二叉树的节点进行查找发现深度为1的节点的查找次数为1，深度为2的查找次数为2，深度为n的节点的查找次数为n，因此其平均查找次数为 (1+2+2+3+3+3) / 6 = 2.3次

二叉查找树可以任意地构造，同样是2,3,5,6,7,8这六个数字，也可以按照下图的方式来构造：
在这里插入图片描述

但是这棵二叉树的查询效率就低了。因此若想 二叉树的查询效率尽可能高，需要这棵二叉树是平衡的，从而引出新的定义—— 平衡二叉树，或称AVL树。

2、平衡二叉树（AVL Tree）

平衡二叉树（AVL树）在符合二叉查找树的条件下，还满足任何节点的两个子树的高度最大差为1。下面的两张图片，左边是AVL树，它的任何节点的两个子树的高度差<=1；右边的不是AVL树，其根节点的左子树高度为3，而右子树高度为1；
在这里插入图片描述

如果在AVL树中进行插入或删除节点，可能导致AVL树失去平衡，这种失去平衡的二叉树可以概括为四种姿态：LL（左左）、RR（右右）、LR（左右）、RL（右左）。

它们的示意图如下：
在这里插入图片描述

2.1、四种失去平衡的定义：

LL：LeftLeft，也称“左左”。插入或删除一个节点后，根节点的左孩子（Left Child）的左孩子（Left Child）还有非空节点，导致根节点的左子树高度比右子树高度高2，AVL树失去平衡。

RR：RightRight，也称“右右”。插入或删除一个节点后，根节点的右孩子（Right Child）的右孩子（Right Child）还有非空节点，导致根节点的右子树高度比左子树高度高2，AVL树失去平衡。

LR：LeftRight，也称“左右”。插入或删除一个节点后，根节点的左孩子（Left Child）的右孩子（Right Child）还有非空节点，导致根节点的左子树高度比右子树高度高2，AVL树失去平衡。

RL：RightLeft，也称“右左”。插入或删除一个节点后，根节点的右孩子（Right Child）的左孩子（Left Child）还有非空节点，导致根节点的右子树高度比左子树高度高2，AVL树失去平衡。

AVL树失去平衡之后，可以通过旋转使其恢复平衡。

2.2、四种失去平衡对应的旋转方法

2.2.1 、LL的旋转

LL失去平衡的情况下，可以通过一次旋转让AVL树恢复平衡。步骤如下：

将根节点的左孩子（K1）作为新根节点。（K1）
将新根节点的右孩子（Y）作为原根节点（K2）的左孩子。（Y）
将原根节点（K2）作为新根节点的右孩子。

LL旋转示意图如下：
在这里插入图片描述

2.2.2 、RR的旋转

RR失去平衡的情况下，旋转方法与LL旋转对称，步骤如下：

将根节点的右孩子（K2）作为新根节点。（K2）
将新根节点的左孩子（Y）作为原根节点（K1）的右孩子。
将原根节点（K1）作为新根节点K2）的左孩子。

RR旋转示意图如下：
在这里插入图片描述

2.2.3、LR的旋转

LR失去平衡的情况下，需要进行两次旋转，步骤如下：

围绕根节点的左孩子进行RR旋转。
围绕根节点进行LL旋转。

LR的旋转示意图如下：
在这里插入图片描述

2.2.4 、RL的旋转

RL失去平衡的情况下也需要进行两次旋转，旋转方法与LR旋转对称，步骤如下：

围绕根节点的右孩子进行LL旋转。
围绕根节点进行RR旋转。

RL的旋转示意图如下：
在这里插入图片描述

3、平衡多路查找树（B-Tree）

B-Tree 是为磁盘等外存储设备设计的一种平衡查找树。因此在讲B-Tree之前先了解下磁盘的相关知识。

系统从磁盘读取数据到内存时是以 磁盘块（block） 为基本单位的，位于同一个磁盘块中的数据会被一次性读取出来，而不是需要什么取什么。

InnoDB存储引擎中有页（Page）的概念，页 是其磁盘管理的最小单位。InnoDB存储引擎中默认每个页的大小为16KB，可通过参数innodb_page_size将页的大小设置为4K、8K、16K，在MySQL中可通过如下命令查看页的大小：

mysql> show variables like 'innodb_page_size' ;

而系统一个磁盘块的存储空间往往没有这么大，因此InnoDB每次申请磁盘空间时都会是若干地址连续磁盘块来达到页的大小16KB。InnoDB在把磁盘数据读入到磁盘时会以页为基本单位，在查询数据时如果一个页中的每条数据都能有助于定位数据记录的位置，这将会减少磁盘I/O次数，提高查询效率。

B-Tree结构的数据可以让系统高效的找到数据所在的磁盘块。为了描述B-Tree，首先定义一条记录为一个二元组[key, data] ，key为记录的键值，对应表中的主键值，data为一行记录中除主键外的数据。对于不同的记录，key值互不相同。

一棵m阶的B-Tree有如下特性：

每个节点最多有m个孩子。
除了根节点和叶子节点外，其它每个节点至少有Ceil(m/2)个孩子。
若根节点不是叶子节点，则至少有2个孩子
所有叶子节点都在同一层，且不包含其它关键字信息
每个非终端节点包含n个关键字信息（P0,P1,…Pn, k1,…kn）
关键字的个数n满足：ceil(m/2)-1 <= n <= m-1
ki(i=1,…n)为关键字，且关键字升序排序。
Pi(i=1,…n)为指向子树根节点的指针。P(i-1)指向的子树的所有节点关键字均小于ki，但都大于k(i-1)

B-Tree中的每个节点根据实际情况可以包含大量的关键字信息和分支。如下图所示为一个3阶的B-Tree：

在这里插入图片描述

每个节点占用一个盘块的磁盘空间，一个节点上有两个升序排序的关键字和三个指向子树根节点的指针，指针存储的是子节点所在磁盘块的地址。两个关键词划分成的三个范围域对应三个指针指向的子树的数据的范围域。以根节点为例，关键字为17和35，P1指针指向的子树的数据范围为小于17，P2指针指向的子树的数据范围为17~35，P3指针指向的子树的数据范围为大于35。

模拟查找关键字29的过程：

根据根节点找到磁盘块1，读入内存。【磁盘I/O操作第1次】
比较关键字29在区间（17,35），找到磁盘块1的指针P2。
根据P2指针找到磁盘块3，读入内存。【磁盘I/O操作第2次】
比较关键字29在区间（26,30），找到磁盘块3的指针P2。
根据P2指针找到磁盘块8，读入内存。【磁盘I/O操作第3次】
在磁盘块8中的关键字列表中找到关键字29。

分析上面过程，发现需要3次磁盘I/O操作，和3次内存查找操作。由于内存中的关键字是一个有序表结构，可以利用 二分法 查找提高效率。而3次磁盘I/O操作是影响整个 B-Tree 查找效率的决定因素。B-Tree 相对于AVL Tree 缩减了节点个数，使每次磁盘I/O取到内存的数据都发挥了作用，从而提高了查询效率。

4、B+Tree

B+Tree 是在B-Tree基础上的一种优化，使其更适合实现外存储索引结构，InnoDB存储引擎就是用 B+Tree 实现其索引结构。

从上一节中的 B-Tree 结构图中可以看到每个节点中不仅包含数据的key值，还有data值。而每一个页的存储空间是有限的，如果data数据较大时将会导致每个节点（即一个页）能存储的key的数量很小，当存储的数据量很大时同样会导致B-Tree的深度较大，增大查询时的磁盘I/O次数，进而影响查询效率。

在B+Tree中，所有数据记录节点都是按照 键值大小 顺序存放在同一层的叶子节点上，而非叶子节点上只存储key值信息，这样可以大大加大每个节点存储的key值数量，降低 B+Tree 的高度。

B+Tree相对于B-Tree有几点不同：

非叶子节点只存 储键值 信息。
所有叶子节点之间都有一个链指针。
数据记录都存放在叶子节点中。

将上一节中的 B-Tree优化，由于 B+Tree 的非叶子节点只存储键值信息，假设每个磁盘块能存储4个键值及指针信息，则变成 B+Tree 后其结构如下图所示：

在这里插入图片描述

通常在B+Tree上有两个头指针，一个指向根节点，另一个指向关键字最小的叶子节点，而且所有叶子节点（即数据节点）之间是一种 链式环结构。因此可以对 B+Tree 进行两种查找运算：

对主键的范围查找和分页查找，
从根节点开始，进行随机查找。

可能上面例子中只有22条数据记录，看不出 B+Tree 的优点，下面做一个推算：

InnoDB存储引擎中页的大小为16KB，一般表的主键类型为INT（占用4个字节）或 BIGINT（占用8个字节），指针类型也一般为4或8个字节，也就是说一个页（B+Tree中的一个节点）中大概存储 16KB/(8B+8B)=1K 个键值（因为是估值，为方便计算，这里的K取值为〖10〗^3） 。也就是说一个深度为3的 B+Tree 索引可以维护 10^3 * 10^3 * 10^3 = 10亿 条记录。

实际情况中每个节点可能不能填充满，因此在数据库中，B+Tree的高度一般都在2~4层 。MySQL的InnoDB存储引擎在设计时是将 根节点 常驻内存的，也就是说查找某一键值的 行记录 时，最多只需要1~3次磁盘I/O操作。

数据库中的B+Tree索引可以分为 聚集索引（clustered index）和 辅助索引（secondary index）。上面的B+Tree示例图在数据库中的实现即为聚集索引，聚集索引的B+Tree中的叶子节点存放的是整张表的行记录数据。

辅助索引与聚集索引的区别：

辅助索引 的 叶子节点 并不包含行记录的全部数据，而是存储相应行数据的聚集索引键，即主键。当通过辅助索引来查询数据时，InnoDB存储引擎会遍历 辅助索引 找到主键，然后再通过主键在 聚集索引 中找到完整的行记录数据。

5、其它

5.1、覆盖扫描

如果一个索引（如：组合索引）中包含所有要查询的字段的值，那么就称之为覆盖索引，如：

SELECT user_name, city, age 
FROM user_test 
WHERE user_name = 'feinik' AND age > 25;

因为要查询的字段（user_name, city, age）都包含在组合索引的索引列中，所以就使用了覆盖索引查询，查看是否使用了 覆盖索引 可以通过执行 explain 中的Extra中的值为 Using index 则证明使用了覆盖索引，覆盖索引 可以极大的提高访问性能。