首先，让我们先看一张图：
从图中可以看到，我们为 user 表（用户信息表）建立了一个二叉查找树的索引。
图中的圆为二叉查找树的节点，节点中存储了键（key）和数据（data）。键对应 user 表中的 id，数据对应 user 表中的行数据。
二叉查找树的特点就是任何节点的左子节点的键值都小于当前节点的键值，右子节点的键值都大于当前节点的键值。顶端的节点我们称为根节点，没有子节点的节点我们称之为叶节点。
如果我们需要查找 id=12 的用户信息，利用我们创建的二叉查找树索引，查找流程如下：
利用二叉查找树我们只需要 3 次即可找到匹配的数据。如果在表中一条条的查找的话，我们需要 6 次才能找到。
上面我们讲解了利用二叉查找树可以快速的找到数据。但是，如果上面的二叉查找树是这样的构造：
这个时候可以看到我们的二叉查找树变成了一个链表。如果我们需要查找 id=17 的用户信息，我们需要查找 7 次，也就相当于全表扫描了。 导致这个现象的原因其实是二叉查找树变得不平衡了，也就是高度太高了，从而导致查找效率的不稳定。为了解决这个问题，我们需要保证二叉查找树一直保持平衡，就需要用到平衡二叉树了。 平衡二叉树又称 AVL 树，在满足二叉查找树特性的基础上，要求每个节点的左右子树的高度差不能超过 1。
下面是平衡二叉树和非平衡二叉树的对比：
由平衡二叉树的构造我们可以发现第一张图中的二叉树其实就是一棵平衡二叉树。
平衡二叉树保证了树的构造是平衡的，当我们插入或删除数据导致不满足平衡二叉树不平衡时，平衡二叉树会进行调整树上的节点来保持平衡。具体的调整方式这里就不介绍了。平衡二叉树相比于二叉查找树来说，查找效率更稳定，总体的查找速度也更快。
因为内存的易失性。一般情况下，我们都会选择将 user 表中的数据和索引存储在磁盘这种外围设备中。但是和内存相比，从磁盘中读取数据的速度会慢上百倍千倍甚至万倍，所以，我们应当尽量减少从磁盘中读取数据的次数。另外，从磁盘中读取数据时，都是按照磁盘块来读取的，并不是一条一条的读。如果我们能把尽量多的数据放进磁盘块中，那一次磁盘读取 *** 作就会读取更多数据，那我们查找数据的时间也会大幅度降低。如果我们用树这种数据结构作为索引的数据结构，那我们每查找一次数据就需要从磁盘中读取一个节点，也就是我们说的一个磁盘块。我们都知道平衡二叉树可是每个节点只存储一个键值和数据的。那说明什么？说明每个磁盘块仅仅存储一个键值和数据！那如果我们要存储海量的数据呢？
可以想象到二叉树的节点将会非常多，高度也会极其高，我们查找数据时也会进行很多次磁盘 IO，我们查找数据的效率将会极低！
为了解决平衡二叉树的这个弊端，我们应该寻找一种单个节点可以存储多个键值和数据的平衡树。也就是我们接下来要说的 B 树。
B 树（Balance Tree）即为平衡树的意思，下图即是一棵 B 树：
图中的 p 节点为指向子节点的指针，二叉查找树和平衡二叉树其实也有，因为图的美观性，被省略了。
图中的每个节点称为页，页就是我们上面说的磁盘块，在 MySQL 中数据读取的基本单位都是页，所以我们这里叫做页更符合 MySQL 中索引的底层数据结构。
从上图可以看出，B 树相对于平衡二叉树，每个节点存储了更多的键值（key）和数据（data），并且每个节点拥有更多的子节点，子节点的个数一般称为阶，上述图中的 B 树为 3 阶 B 树，高度也会很低。
基于这个特性，B 树查找数据读取磁盘的次数将会很少，数据的查找效率也会比平衡二叉树高很多。
假如我们要查找 id=28 的用户信息，那么我们在上图 B 树中查找的流程如下：
B+ 树是对 B 树的进一步优化。让我们先来看下 B+ 树的结构图：
根据上图我们来看下 B+ 树和 B 树有什么不同：
通过上图可以看到，在 InnoDB 中，我们通过数据页之间通过双向链表连接以及叶子节点中数据之间通过单向链表连接的方式可以找到表中所有的数据。
MyISAM 中的 B+ 树索引实现与 InnoDB 中的略有不同。在 MyISAM 中，B+ 树索引的叶子节点并不存储数据，而是存储数据的文件地址。
摘自： http://www.liuzk.com/410.html
问题：MySQL的索引B+树叶子节点上的数据记录是通过单向链表还是双向链表组织起来的？
本文的观点是基于MySQL使用Innodb存储引擎的情况下进行的！ 很多渠道说：MySQL数据按照主键大小依次排列，记录之间是双向链表连起来。如果说我告诉你这种说法很大程度上是错的，你肯定说我在胡扯。
我们先看看MySQL的B+树索引结构是什么样的
是的，这种图和网上的很多图都是类似的，我们可以看到每个节点上会有多个记录或者数据，MySQL使用Innob引擎时，这个节点就代表的是Innodb页，Innodb页是最小的存储单元。
通过上图或者你以前就知道，一个Innodb页存储很多条数据。 但是Innodb页可不只有数据记录，还会有其他数据
同样每条记录也不单单只有数据本身，还包含其他额外的数据，我的上篇文章有这么一幅图
其中额外信息中，有记录头信息部分，这部分到底长什么样呢
记录头占 5 个字节，40 位，下图是对应代表的含义
这里我们着重看一下下条记录的相对位置部分： 什么是相对位置呢？简要回答就是我离你有多远，而不是起点离你有多远。 放在MySQL里代表记录之间的距离。
下面我们借助另一张图看一下，看一下Innodb页中记录之间是怎么存储的
上图中我们看到，记录之间是亲密无间的排列的。 那我们怎么找下一条记录呢，还是看上面的出现的一张图，里面的下条记录的相对位置
比如，记录1的中下条记录的相对位置为38，意味着从记录1的真实数据开始往后找38个字节就是下一条记录的真实数据的开始。如果记录1的下条记录的相对位置是-38，代表从记录1的真实数据部分往前找38个字节就是下一条记录的真实数据部分。
如果你了解数据结构，你一定明白，这特么就是链表啊！ 是的，Innodb页中的数据之间，是通过单向链表来实现的。
但是，Innodb页之间是双向链表关联的。
一个Innodb页中的文件头中有这么两个属性：上一页的页号、下一页的页号
所以MySQL叶子节点之间是通过双向链表完成的。
Mysql中记录间既有单向链表，又有双向链表！
因为4层分支太多。树插入都是在叶子结点进行的，就是插入前，需要先找到要插入的叶子结点。如果被插入关键字的叶子节点，当前含有的关键字数量是小于阶数，则直接插入。当数量达到4的时候树已经承受不住这么多的层，所以不能设置。
树层数量一般最多就是到3层。这个概念就好像指数爆炸是一样的越长越多。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）