MySQL索引为什么要用B+树实现？

前言

在从一堆数据中查找指定的数据时，我们常用的数据结构是哈希表和二叉查找树，表本质上就是一堆数据的集合，所以MySQL数据库用了B+树和哈希表来实现索引

B+树是通过二叉查找树，再由平衡二叉树，B树（又名B-树）演化而来的，B+树中的B不是代表二叉（binary），而是代表平衡（balance），因为B+树是从最早的平衡二叉树演化而来，但是B+树不是一个二叉树

二叉查找树和平衡二叉树

二叉查找树的效率和平衡二叉树的查找效率已经很高了，为什么不用这两种数据结构来实现索引呢？慢慢来分析

二叉查找树是带有特殊属性的二叉树，需要满足以下属性

1. 非叶子节点最多拥有两个子节点
2. 非叶子节值大于左边子节点、小于右边子节点
3. 没有值相等重复的节点;

对上图这个二叉树进行查找，如查键值为5的记录，先找到根，其值时6，大于5，查找6的左子树，找到3，5大于3，再找其右子树，一共找了3次。同理，查找键值为8的记录，用了3次。所有键值平均查找次数为(1+2+2+3+3+3)/6=2.3次，假如对这些键值进行顺序查找，平均查找次数为(1+2+3+4+5+6)/6=3.3（查找顺序摆放的数，第一个数肯定是1次，而第2个数是2次，以此类推），显然二叉查找树的平均查找速度比顺序查找更快

二叉查找树可以任意的构造，假如二叉查找树按照如下方式构造

平均查找速度为(1+2+3+4+5+5)/6=3.16次，和顺序查找差不多。为了提高二叉查找树的查询效率，需要二叉查找数是平衡的，这就引出了平衡二叉树。

平衡二叉树除了满足上面3个属性，还要满足如下1个属性

1. 树的左右两边的层级数相差不会大于1
2. 
   

平衡二叉树的查找效率确实很快，但维护一颗平衡二叉树的代价是非常大的，需要1次或多次左旋和右旋来得到插入或更新后树的平衡性。简单举个例子。

初始平衡二叉树

插入3

右旋一次

再左旋一次

作为一个科普性的文章，这里不对左旋的右旋的细节进行分析，放几个图片能理解左旋和右旋即可

对x进行左旋，意味着将x变为一个左结点

对y进行右旋，意味着将y变为一个右节点

回头看上面例子的左旋和右旋，是不是很清楚了？

B树和B+树

B树和B-树是同一种树，假如用平衡二叉树实现索引，效率已经很高了，查找一个节点所做的IO次数是这个节点所处的树的高度，因为我们无法把整个索引都加载到内存，并且节点数据在磁盘中不是顺序排放的。所以最坏情况下，磁盘的IO次数为树的高度。

虽然平衡二叉树查找效率确实很高，但是频繁的IO才是阻碍提高性能的瓶颈，怎样减少IO次数呢？前辈们很聪明的提出了局部性原理，分为时间局部性原理，即假如你查询id为1的用户数据，过一段时间你还会查询id为1的数据，所以会将这部分数据缓存下来。空间局部性原理，当你查询id为1的用户数据的时候，你有很大的概率会去查询id为2，3，4的用户的数据，所以会一次性的把id为1，2，3，4的数据都读到内存中去，这个最小的单位就是页。

B树和B+树的概念比较复杂，有兴趣的小伙伴可以点原文链接看看知乎上写的一篇文章，这里只做一个宏观的介绍，前文已经提到树高决定着IO的次数，那么降低树高不就能减少IO的次数吗，怎么减少呢，每个节点的数据多放一点不就行了，并且这个数据是存放在一块的，对应的是数据库中的读取的最小单位页，一次IO就可以将这些数据读取出来，虽然比较的次数有可能会增加，但是在内存中的比较和磁盘IO相比差几个数量级，整体上效率还是提高了。

所以你看到的B树是这样的

B+树是这样的

那么B树和B+树的区别在哪呢？

1. B+跟B树不同B+树的非叶子节点不保存键值对应的数据，这样使得B+树每个节点所能保存的键值大大增加；
2. B+树叶子节点保存了父节点的所有键值和键值对应的数据，每个叶子节点的键值从小到大链接；
3. B+树的根节点键值数量和其子节点个数相等;
4. B+的非叶子节点只进行数据索引，不会存实际的键值对应的数据，所有数据必须要到叶子节点才能获取到，​所以每次数据查询的次数都一样；

放个图理解的更清楚一点，B树

B+树

在B+树的基础上每个节点存储的关键字数更多，树的层级更少所以查询数据更快，所有关键字数据都存在叶子节点，所以每次查找的次数都相同，查询速度比B树更稳定。除此之外，B+树的叶子节点是跟后序节点相连接的，这对范围查找是非常有用的。

聚集索引和联合索引

在InnoDB存储引擎中，是以主键为索引来组织数据的。在InnoDB存储引擎中，每张表都有个主键，如果在创建表时没有显示的定义主键，则InnoDB存储引擎会按如下方式选择或创建主键。

1. 首先判断表中是否有非空的唯一索引，如果有，则该列即为主键
2. 如果不符合上述条件，InnoDB存储引擎自动创建一个6字节大小的指针作为索引
3. 如果有多个非空唯一索引时，InnoDB存储引擎将选择建表时第一个定义的非空唯一索引作为主键

假如说有如下数据，用户id为主键（1， tom），（2，mike），（3，sam），（4，lisa），（5，li）则数据是这样存储的，图1

假如说我们现在对用户名建索引，用户名索引是怎么存的呢？图2

用户名索引叶子节点数据存储的是主键，所以当我们运行如下sql语句时

select * from table where name ="sam"

过程是这样的，先在name索引上找到对应的主键，在根据对应的主键去建表时建立的B+树上找到对应的记录，即先在图1上找，再到图2上找。

聚集索引：数据行的物理顺序与列值（一般是主键的那一列）的逻辑顺序相同，一个表中只能拥有一个聚集索引。图1用的就是聚集索引

非聚集索引：定义：该索引中索引的逻辑顺序与磁盘上行的物理存储顺序不同，一个表中可以拥有多个非聚集索引。图2用的就是非聚集索引

最后再说一个联合索引，联合索引是指对表上的多个列进行索引。创建方式如下：

CREATE TABLE `t` (
 `a` int(10),
 `b` int(10),
 PRIMARY KEY (`a`),
 KEY `idx_a_b` (`a`,`b`)
) ENGINE=InnoDB;

联合索引也是一颗B+树，不同的是联合索引的键值的数量不是1，而是大于等于2，多个键值的B+树是如下存的

可以看到键值都是排序的，就上面的例子来说（1，1）（1，2）（2，1）（2，4）（3，1）（3，2），数据按照（a，b）的顺序进行了存放。

因此对于查询select * from table where a = xxx and b = xxx，显然是可以使用（a，b）这个联合索引的。对于单个的a列查询select * from table where a = xxx，也可以使用（a，b）这个索引。但对于b列的查询select * from table where b = xxx，则不可以使用这颗B+树索引。可以发现叶子节点上的b值为1，2，1，4，1，2，显然不是排序的，因此对于b列的查询使用不到（a，b）的索引

自适应哈希索引

InnoDB存储引擎会监控对表上各项索引页的查询。如果观察到建立哈希索引可以带来速度提升，则建立哈希索引，称之为自适应哈希索引，DBA不能对建立哈希索引的过程进行干预，只能启动或禁用自适应哈希索引

数据库一般采用除法散列的方法，即取k除以m的余数，将关键词k映射到m个槽的某一个去，即哈希函数为h(k) = k mod m，当发生冲突时，即两个关键字可能映射到同一个槽上，采用链接法，即以链表的形式保存冲突的关键字，和HashMap类似

当对热点数据建立了哈希索引以后，省去在B+树上进行查找，可以极大地提高服务的性能，自适应哈希索引对于字典类型的查找非常迅速，如select * from table where id = xxx，但是对于范围查找就无能无力了

文章转载自公众号：Java识堂