B+树索引是B+树在数据库中的一种实现,是最多见也是数据库中使用最为频繁的一种索引。B+树中的B表明平衡(balance),而不是二叉(binary),由于B+树是从最先的平衡二叉树演化而来的。在讲B+树以前必须先了解二叉查找树、平衡二叉树(AVLTree)和平衡多路查找树(B-Tree),B+树即由这些树逐步优化而来。mysql
二叉树具备如下性质:左子树的键值小于根的键值,右子树的键值大于根的键值。
以下图所示就是一棵二叉查找树,
对该二叉树的节点进行查找发现深度为1的节点的查找次数为1,深度为2的查找次数为2,深度为n的节点的查找次数为n,所以其平均查找次数为 (1+2+2+3+3+3) / 6 = 2.3次sql
二叉查找树能够任意地构造,一样是2,3,5,6,7,8这六个数字,也能够按照下图的方式来构造:
可是这棵二叉树的查询效率就低了。所以若想二叉树的查询效率尽量高,须要这棵二叉树是平衡的,从而引出新的定义——平衡二叉树,或称AVL树。数据库
平衡二叉树(AVL树)在符合二叉查找树的条件下,还知足任何节点的两个子树的高度最大差为1。下面的两张图片,左边是AVL树,它的任何节点的两个子树的高度差<=1;右边的不是AVL树,其根节点的左子树高度为3,而右子树高度为1; 优化
若是在AVL树中进行插入或删除节点,可能致使AVL树失去平衡,这种失去平衡的二叉树能够归纳为四种姿态:LL(左左)、RR(右右)、LR(左右)、RL(右左)。它们的示意图以下: spa
这四种失去平衡的姿态都有各自的定义:
LL:LeftLeft,也称“左左”。插入或删除一个节点后,根节点的左孩子(Left Child)的左孩子(Left Child)还有非空节点,致使根节点的左子树高度比右子树高度高2,AVL树失去平衡。.net
RR:RightRight,也称“右右”。插入或删除一个节点后,根节点的右孩子(Right Child)的右孩子(Right Child)还有非空节点,致使根节点的右子树高度比左子树高度高2,AVL树失去平衡。设计
LR:LeftRight,也称“左右”。插入或删除一个节点后,根节点的左孩子(Left Child)的右孩子(Right Child)还有非空节点,致使根节点的左子树高度比右子树高度高2,AVL树失去平衡。指针
RL:RightLeft,也称“右左”。插入或删除一个节点后,根节点的右孩子(Right Child)的左孩子(Left Child)还有非空节点,致使根节点的右子树高度比左子树高度高2,AVL树失去平衡。code
AVL树失去平衡以后,能够经过旋转使其恢复平衡。下面分别介绍四种失去平衡的状况下对应的旋转方法。排序
LL的旋转。LL失去平衡的状况下,能够经过一次旋转让AVL树恢复平衡。步骤以下:
LL旋转示意图以下:
RR的旋转:RR失去平衡的状况下,旋转方法与LL旋转对称,步骤以下:
RR旋转示意图以下:
LR的旋转:LR失去平衡的状况下,须要进行两次旋转,步骤以下:
LR的旋转示意图以下:
RL的旋转:RL失去平衡的状况下也须要进行两次旋转,旋转方法与LR旋转对称,步骤以下:
RL的旋转示意图以下:
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有以下特性:
1. 每一个节点最多有m个孩子。
2. 除了根节点和叶子节点外,其它每一个节点至少有Ceil(m/2)个孩子。
3. 若根节点不是叶子节点,则至少有2个孩子
4. 全部叶子节点都在同一层,且不包含其它关键字信息
5. 每一个非终端节点包含n个关键字信息(P0,P1,…Pn, k1,…kn)
6. 关键字的个数n知足:ceil(m/2)-1 <= n <= m-1
7. ki(i=1,…n)为关键字,且关键字升序排序。
8. 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的过程:
分析上面过程,发现须要3次磁盘I/O操做,和3次内存查找操做。因为内存中的关键字是一个有序表结构,能够利用二分法查找提升效率。而3次磁盘I/O操做是影响整个B-Tree查找效率的决定因素。B-Tree相对于AVLTree缩减了节点个数,使每次磁盘I/O取到内存的数据都发挥了做用,从而提升了查询效率。
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存储引擎会遍历辅助索引找到主键,而后再经过主键在汇集索引中找到完整的行记录数据。