MySql的底层数据结构竟然是...

2023-04-20 00:00:00 数据 节点 子树 磁盘 查找

背景

索引结构及查找算法

一个sql语句在mysql里究竟是如何运行的呢?又是怎么去查找的呢? 其中就涉及到数据库(存储数据)以及查找算法。 先来看一下几种查找算法;

  • 目录查找:类似索引
  • 遍历:暴力查找
  • 二分:B+树的基础算法
  • 键查找:hash查找

能做索引的数据结构有:数组、链表、红黑树、B树(B-树、B+树)。

那么哪种数据结构适合做 MySql 数据库的存储结构呢?

先来说下数据的一般存储方式:内存(适合小数据量)、磁盘(大数据量)。
磁盘的运转方式:速度 + 旋转,磁盘页的概念:每一页大概16KB。

不适合做MySql的数据结构及其原因

数组和链表的缺点就是数据量大的时候存不了,也就是说不合适大数据量。

哈希是通过hash函数计算出一个hash值的,存在哈希碰撞的情况,另外哈希也不支持部分索引查询以及范围查找。但是哈希的优点就是查找的时间复杂度是O(1),那么什么情况下可以使用hash索引呢?就是查询条件不会变,而且没有部分查询和范围查询的时候。

红黑树存储的数据量大的时候,红黑树的节点层数多,也就是树的高度比较高,查找的底层数据时,查找次数就比较多,即对磁盘IO使用比较频繁。总结为以下两点: 1. 读取浪费太多:通过计算本来树的每一层大概需要分配16KB的数据,但是对于红黑树来说,实际存的节点数比较少,即存的数据大小远远小于16KB,从而造成存储空间的浪费 2. 读取磁盘的次数过多:树的层数越多,查找数据时读取磁盘的次数也就越多

如下图所示,如果需要查找数字4的话,需要查找三次,即对磁盘IO操作三次:



我们想下,那为什么红黑树又可以在hashMap的查找那里用呢?
这就涉及到磁盘和内存的区别了,这里就不展开解释了,只需要知道是因为hashMap使用到是内存就可以了。

BTree和B+Tree的引出

针对红黑树以上总结的两点(不适合用来做mysql的数据结构的原因),有什么可以改进的方法呢?我们可以从以下两点出发:

  1. 增加树每层的节点数量,这样可以对分配的16KB充分利用,即解决上面的读取浪费的问题
  2. 尽可能的让树的高度减小,使得树显得比较“矮胖”,这样可以减少读取磁盘的次数

那么怎么样才可以实现以上的方法呢?这就需要用到B+树了,实际上MySql的底层数据结构就是用的B+树。

BTree数据结构

N阶的BTree的几个重要特性:

  1. 节点多含有N颗子树(指针),N-1个关键字(数据存储空间) (N>=2);
  2. 除了根节点和叶子节点外,其它每个节点至少有M=N/2个子节点,M向上取整,即分裂的时候从中间分开,分成M棵子树;
  3. 若根节点不是叶子结点,则至少有两颗子树。

什么意思呢,我们来看下面这颗三阶的B树,结构大概长这样:



BTree有一个非常重要的操作,当一颗树不满足以上的性质的时候,会进行怎样的操作?红黑色大家已经知道了会进行变换颜色、左旋或右旋操作(二叉树、红黑树以及Golang实现红黑树)。而BTree会进行分裂操作。

先来看个例子:

创建一棵5阶的BTree,插入的数据有:2,13,6,1,7,4,10,12,5,16,22。
根据BTree的特性,5阶则在磁盘的页中多有5个指针(存储查找路径的地址)、4个存储空间(存储关键字,即需要存的数据),那么具体的插入数据如下所示:


当插入7的时候,发现空间不足,此时就会出现分裂操作,从中间节点分开,把中间节点移到根节点,如下:


当插入16的时候,比6大,应该插入到右子树13的右边的,但是发现的空间不够,此时又会进行分裂操作,从右子树的中间节点(12)分开,把中间节点移到根节点,然后分裂成左右子树,这时一共有三颗子树了,如下所示:


后插入22得到的一颗完整的树如下:


大家也可以添加多其它数据,然后看看分裂后的效果,这里就不一一列举了。

需要注意的是:分裂后的树节点仍要满足BTree的特性,其实也是满足二叉查找树(二叉排序树)的特点,如果忘了的同学,可以参考前面写的一篇文章:二叉树、红黑树以及Golang实现红黑树。
可以看到左子树的值比6小,中间节点的值(7、10)介于6和12之间,右子树的值均比12大。总的来说就是从左到右是有序的。

以上操作是BTree构建的详细过程,需要注意的是在构建过程中进行分裂的操作,分裂后必须关注的是是否仍满足了BTree的特性,是否是一颗二叉排序树。有时候插入一个数时,可能会经过多次分裂操作。

回过头来看上面提到的两个问题:1.读取浪费太多;2.磁盘读取次数过多。根据BTree的特点,我们可以看到BTree的查找效率还是挺高的,也能够解决这两个问题。但是MySql还是没有选择使用BTree数据结构,这是为什么呢?

主要原因有以下这几点: 1. 因为BTree不适合范围查找。就拿上面的来举例,比如我要查找小于6的数据,则先找到6的节点,然后需要遍历一遍6节点(索引)的左子树,不遍历的话,就拿不到小于6的这些数据了,也就说索引失效了,所以说不适合范围查找。 2. BTree的节点除了存储索引之外,还存储了数据本身,占用空间较大,但是磁盘的页大小是有限的(16KB左右),因此,存储同样大小的数据,BTree显得比较高(相对B+Tree),稳定性弱一些。

综上两个主要原因,MySql终选择了B+Tree的数据结构来存储数据。

B+Tree数据结构

B+Tree和BTree的分裂过程类似,只是B+Tree的非叶子节点不会存储数据,所有的数据都是存储在叶子节点,其目的是为了增加系统的稳定性。这里就不再列举B+Tree的分裂过程了,我们直接看下B+Tree到底长啥样,如下图所示:



实际上MySql的底层数据结构B+Tree是长这样的,如下图所示:



大家可以看出B+Tree与BTree有啥不一样呢?由上图可以看出B+Tree有以下几个特点: 1. 叶子节点连起来了,是一条有序的双向链表,目的是为了解决范围查找。比如需要查找小于9的数据,只要找到等于9的数据,然后将9的左边数据全部拿出来即可。 2. 非叶子节点不存数据,只存索引,空间利用更高效。 3. 数据的个数和节点一样多,换句话说,非叶子节点存的是其子树的大或小值。

对于索引失效的情况,BTree是需要遍历整棵树才能把所有数据拿到,而B+Tree只需要找到叶子节点的个节点即可把所有数据拿到,可见效率是B+Tree更优,这就是双向链表的妙用。

计算m阶,即B+Tree该取多少合适

m是怎么计算出来的呢?是根据磁盘的页大小来结算的,也就是说是由页大小决定的。

我们知道,磁盘的页大小大概是16K,MySql创建索引时,可以根据字段及类型来计算磁盘一页大概可以存多少数据。
根据官方文档描述,树高度等于2时(2阶),大概可以存两万多条数据;高度等于3时(3阶),大概可以存两千多万条数据,怎么计算的呢?
首先,1 千字节(KB)=1024 字节(B),一页有16KB,假设存主键+指针大概有14B(8+6),则一页就可以存:16*1024/(8+6)=1170 个索引了。

对于3阶的B+Tree来说,大概可以存:1170^3 条数据,约等于两千万。

总结

BTree是B+Tree的一个过渡,B+Tree适合用于大数据量的磁盘索引数,经典的就是上面讲到的作为MySql的底层索引结构,所有的数据都存在叶子节点,其它节点只存储索引,增加了系统的稳定性、提高查找效率以及查询时减少磁盘的IO操作。

相关文章