终于有篇看的懂的B树文章了！

索引，相信大多数人已经至关熟悉了，不少人都知道 MySQL 的索引主要以 B+ 树为主，可是要问到为何用 B+ 树，恐怕不多有人能把来龙去脉讲述完整。本文就来从头至尾介绍下数据库的索引。

图片来自 Pexels

索引是一种数据结构，用于帮助咱们在大量数据中快速定位到咱们想要查找的数据。

索引最形象的比喻就是图书的目录了。注意这里的大量，数据量大了索引才显得有意义，若是我想要在 [1,2,3,4] 中找到 4 这个数据，直接对全数据检索也很快，没有必要费力气建索引再去查找。

索引在 MySQL 数据库中分三类： 

• B+ 树索引

• Hash 索引

• 全文索引

咱们今天要介绍的是工做开发中最常接触到的 InnoDB 存储引擎中的 B+ 树索引。

要介绍 B+ 树索引，就不得不提二叉查找树，平衡二叉树和 B 树这三种数据结构。B+ 树就是从他们仨演化来的。

二叉查找树

首先，让咱们先看一张图：

从图中能够看到，咱们为 user 表（用户信息表）创建了一个二叉查找树的索引。

图中的圆为二叉查找树的节点，节点中存储了键（key）和数据（data）。键对应 user 表中的 id，数据对应 user 表中的行数据。

二叉查找树的特色就是任何节点的左子节点的键值都小于当前节点的键值，右子节点的键值都大于当前节点的键值。顶端的节点咱们称为根节点，没有子节点的节点咱们称之为叶节点。 

若是咱们须要查找 id=12 的用户信息，利用咱们建立的二叉查找树索引，查找流程以下： 

• 将根节点做为当前节点，把 12 与当前节点的键值 10 比较，12 大于 10，接下来咱们把当前节点>的右子节点做为当前节点。 

• 继续把 12 和当前节点的键值 13 比较，发现 12 小于 13，把当前节点的左子节点做为当前节点。 

• 把 12 和当前节点的键值 12 对比，12 等于 12，知足条件，咱们从当前节点中取出 data，即 id=12，name=xm。

利用二叉查找树咱们只须要 3 次便可找到匹配的数据。若是在表中一条条的查找的话，咱们须要 6 次才能找到。

平衡二叉树

上面咱们讲解了利用二叉查找树能够快速的找到数据。可是，若是上面的二叉查找树是这样的构造：

这个时候能够看到咱们的二叉查找树变成了一个链表。若是咱们须要查找 id=17 的用户信息，咱们须要查找 7 次，也就至关于全表扫描了。 

致使这个现象的缘由实际上是二叉查找树变得不平衡了，也就是高度过高了，从而致使查找效率的不稳定。

为了解决这个问题，咱们须要保证二叉查找树一直保持平衡，就须要用到平衡二叉树了。 
平衡二叉树又称 AVL 树，在知足二叉查找树特性的基础上，要求每一个节点的左右子树的高度差不能超过 1。 

下面是平衡二叉树和非平衡二叉树的对比：

由平衡二叉树的构造咱们能够发现第一张图中的二叉树其实就是一棵平衡二叉树。

平衡二叉树保证了树的构造是平衡的，当咱们插入或删除数据致使不知足平衡二叉树不平衡时，平衡二叉树会进行调整树上的节点来保持平衡。具体的调整方式这里就不介绍了。

平衡二叉树相比于二叉查找树来讲，查找效率更稳定，整体的查找速度也更快。

B 树

由于内存的易失性。通常状况下，咱们都会选择将 user 表中的数据和索引存储在磁盘这种外围设备中。

可是和内存相比，从磁盘中读取数据的速度会慢上百倍千倍甚至万倍，因此，咱们应当尽可能减小从磁盘中读取数据的次数。

另外，从磁盘中读取数据时，都是按照磁盘块来读取的，并非一条一条的读。

若是咱们能把尽可能多的数据放进磁盘块中，那一次磁盘读取操做就会读取更多数据，那咱们查找数据的时间也会大幅度下降。

若是咱们用树这种数据结构做为索引的数据结构，那咱们每查找一次数据就须要从磁盘中读取一个节点，也就是咱们说的一个磁盘块。

咱们都知道平衡二叉树但是每一个节点只存储一个键值和数据的。那说明什么？说明每一个磁盘块仅仅存储一个键值和数据！那若是咱们要存储海量的数据呢？

能够想象到二叉树的节点将会很是多，高度也会极其高，咱们查找数据时也会进行不少次磁盘 IO，咱们查找数据的效率将会极低！

为了解决平衡二叉树的这个弊端，咱们应该寻找一种单个节点能够存储多个键值和数据的平衡树。也就是咱们接下来要说的 B 树。 

B 树（Balance Tree）即为平衡树的意思，下图便是一棵 B 树：

图中的 p 节点为指向子节点的指针，二叉查找树和平衡二叉树其实也有，由于图的美观性，被省略了。

图中的每一个节点称为页，页就是咱们上面说的磁盘块，在 MySQL 中数据读取的基本单位都是页，因此咱们这里叫作页更符合 MySQL 中索引的底层数据结构。

从上图能够看出，B 树相对于平衡二叉树，每一个节点存储了更多的键值（key）和数据（data），而且每一个节点拥有更多的子节点，子节点的个数通常称为阶，上述图中的 B 树为 3 阶 B 树，高度也会很低。 

基于这个特性，B 树查找数据读取磁盘的次数将会不多，数据的查找效率也会比平衡二叉树高不少。 
假如咱们要查找 id=28 的用户信息，那么咱们在上图 B 树中查找的流程以下： 

• 先找到根节点也就是页 1，判断 28 在键值 17 和 35 之间，那么咱们根据页 1 中的指针 p2 找到页 3。 

• 将 28 和页 3 中的键值相比较，28 在 26 和 30 之间，咱们根据页 3 中的指针 p2 找到页 8。 

• 将 28 和页 8 中的键值相比较，发现有匹配的键值 28，键值 28 对应的用户信息为（28，bv）。

B+ 树

B+ 树是对 B 树的进一步优化。让咱们先来看下 B+ 树的结构图：

根据上图咱们来看下 B+ 树和 B 树有什么不一样：

①B+ 树非叶子节点上是不存储数据的，仅存储键值，而 B 树节点中不只存储键值，也会存储数据。

之因此这么作是由于在数据库中页的大小是固定的，InnoDB 中页的默认大小是 16KB。

若是不存储数据，那么就会存储更多的键值，相应的树的阶数（节点的子节点树）就会更大，树就会更矮更胖，如此一来咱们查找数据进行磁盘的 IO 次数又会再次减小，数据查询的效率也会更快。

另外，B+ 树的阶数是等于键值的数量的，若是咱们的 B+ 树一个节点能够存储 1000 个键值，那么 3 层 B+ 树能够存储 1000×1000×1000=10 亿个数据。

通常根节点是常驻内存的，因此通常咱们查找 10 亿数据，只须要 2 次磁盘 IO。 

②由于 B+ 树索引的全部数据均存储在叶子节点，并且数据是按照顺序排列的。

那么 B+ 树使得范围查找，排序查找，分组查找以及去重查找变得异常简单。而 B 树由于数据分散在各个节点，要实现这一点是很不容易的。  

有心的读者可能还发现上图 B+ 树中各个页之间是经过双向链表链接的，叶子节点中的数据是经过单向链表链接的。

其实上面的 B 树咱们也能够对各个节点加上链表。这些不是它们以前的区别，是由于在 MySQL 的 InnoDB 存储引擎中，索引就是这样存储的。

也就是说上图中的 B+ 树索引就是 InnoDB 中 B+ 树索引真正的实现方式，准确的说应该是汇集索引（汇集索引和非汇集索引下面会讲到）。

经过上图能够看到，在 InnoDB 中，咱们经过数据页之间经过双向链表链接以及叶子节点中数据之间经过单向链表链接的方式能够找到表中全部的数据。

MyISAM 中的 B+ 树索引实现与 InnoDB 中的略有不一样。在 MyISAM 中，B+ 树索引的叶子节点并不存储数据，而是存储数据的文件地址。

汇集索引 VS 非汇集索引

在上节介绍 B+ 树索引的时候，咱们提到了图中的索引实际上是汇集索引的实现方式。

那什么是汇集索引呢？在 MySQL 中，B+ 树索引按照存储方式的不一样分为汇集索引和非汇集索引。

这里咱们着重介绍 InnoDB 中的汇集索引和非汇集索引：

①汇集索引（聚簇索引）：以 InnoDB 做为存储引擎的表，表中的数据都会有一个主键，即便你不建立主键，系统也会帮你建立一个隐式的主键。

这是由于 InnoDB 是把数据存放在 B+ 树中的，而 B+ 树的键值就是主键，在 B+ 树的叶子节点中，存储了表中全部的数据。

这种以主键做为 B+ 树索引的键值而构建的 B+ 树索引，咱们称之为汇集索引。 

②非汇集索引（非聚簇索引）：以主键之外的列值做为键值构建的 B+ 树索引，咱们称之为非汇集索引。

非汇集索引与汇集索引的区别在于非汇集索引的叶子节点不存储表中的数据，而是存储该列对应的主键，想要查找数据咱们还须要根据主键再去汇集索引中进行查找，这个再根据汇集索引查找数据的过程，咱们称为回表。

明白了汇集索引和非汇集索引的定义，咱们应该明白这样一句话：数据即索引，索引即数据。

利用汇集索引和非汇集索引查找数据

前面咱们讲解 B+ 树索引的时候并无去说怎么在 B+ 树中进行数据的查找，主要就是由于尚未引出汇集索引和非汇集索引的概念。

下面咱们经过讲解如何经过汇集索引以及非汇集索引查找数据表中数据的方式介绍一下 B+ 树索引查找数据方法。

利用汇集索引查找数据

仍是这张 B+ 树索引图，如今咱们应该知道这就是汇集索引，表中的数据存储在其中。

如今假设咱们要查找 id>=18 而且 id<40 的用户数据。对应的 sql 语句为：

select * from user where id>=18 and id <40

其中 id 为主键，具体的查找过程以下：

①通常根节点都是常驻内存的，也就是说页 1 已经在内存中了，此时不须要到磁盘中读取数据，直接从内存中读取便可。

从内存中读取到页 1，要查找这个 id>=18 and id <40 或者范围值，咱们首先须要找到 id=18 的键值。

从页 1 中咱们能够找到键值 18，此时咱们须要根据指针 p2，定位到页 3。

②要从页 3 中查找数据，咱们就须要拿着 p2 指针去磁盘中进行读取页 3。

从磁盘中读取页 3 后将页 3 放入内存中，而后进行查找，咱们能够找到键值 18，而后再拿到页 3 中的指针 p1，定位到页 8。

③一样的页 8 页不在内存中，咱们须要再去磁盘中将页 8 读取到内存中。

将页 8 读取到内存中后。由于页中的数据是链表进行链接的，并且键值是按照顺序存放的，此时能够根据二分查找法定位到键值 18。

此时由于已经到数据页了，此时咱们已经找到一条知足条件的数据了，就是键值 18 对应的数据。

由于是范围查找，并且此时全部的数据又都存在叶子节点，而且是有序排列的，那么咱们就能够对页 8 中的键值依次进行遍历查找并匹配知足条件的数据。

咱们能够一直找到键值为 22 的数据，而后页 8 中就没有数据了，此时咱们须要拿着页 8 中的 p 指针去读取页 9 中的数据。

④由于页 9 不在内存中，就又会加载页 9 到内存中，并经过和页 8 中同样的方式进行数据的查找，直到将页 12 加载到内存中，发现 41 大于 40，此时不知足条件。那么查找到此终止。

最终咱们找到知足条件的全部数据，总共 12 条记录：

(18,kl),(19,kl),(22,hj),(24,io),(25,vg),(29,jk),(31,jk),(33,rt),(34,ty),(35,yu),(37,rt),(39,rt)。

下面看下具体的查找流程图：

利用非汇集索引查找数据

读者看到这张图的时候可能会蒙，这是啥东西啊？怎么都是数字。若是有这种感受，请仔细看下图中红字的解释。

什么？还看不懂？那我再来解释下吧。首先，这个非汇集索引表示的是用户幸运数字的索引（为何是幸运数字？一时兴起想起来的:-)），此时表结构是这样的。

在叶子节点中，再也不存储全部的数据了，存储的是键值和主键。对于叶子节点中的 x-y，好比 1-1。左边的 1 表示的是索引的键值，右边的 1 表示的是主键值。

若是咱们要找到幸运数字为 33 的用户信息，对应的 sql 语句为：

select * from user where luckNum=33

查找的流程跟汇集索引同样，这里就不详细介绍了。咱们最终会找到主键值 47，找到主键后咱们须要再到汇集索引中查找具体对应的数据信息，此时又回到了汇集索引的查找流程。  
下面看下具体的查找流程图：

在 MyISAM 中，汇集索引和非汇集索引的叶子节点都会存储数据的文件地址。

总结

本篇文章从二叉查找树，详细说明了为何 MySQL 用 B+ 树做为数据的索引，以及在 InnoDB 中数据库如何经过 B+ 树索引来存储数据以及查找数据。

咱们必定要记住这句话：数据即索引，索引即数据。