MySQL的B+树索引结构

最新推荐文章于 2024-07-18 20:04:15 发布

道生壹贰

最新推荐文章于 2024-07-18 20:04:15 发布

阅读量493

点赞数 1

分类专栏： MySQL 文章标签： mysql b树数据结构 b+树

原文链接：https://mp.weixin.qq.com/s/XX_NkIIf_PLyU4IE6lEEYQ

版权

MySQL 专栏收录该内容

7 篇文章 1 订阅

订阅专栏

以下文章来源于公众号：小白debug ，作者小白

页的结构

假设我们有一张user数据表
在这里插入图片描述
其中id是唯一主键。

这看起来的一行行数据，为了方便，我们后面就叫他record吧。

这张表看起来就跟excel表格一样。excel的数据在硬盘上是xx.excel的文件。

而上面user表数据，在硬盘上其实也是类似，放在了user.ibd文件下。

含义是user表的innodb data文件，专业点，又叫表空间。

虽然在数据表里，他们看起来是挨在一起的。但实际上在user.idb里他们被分成很多小份的数据页，每份大小16K。

类似于下面这样。
在这里插入图片描述
我们把视角聚集一下，放到页上面。

整个页16K，不大，但record这么多，一页肯定放不下，所以会分开放到很多页里。
并且这16K，还要存放除record之外的其他信息。

因为record被分成好多份，放到好多页里了，为了唯一标识具体是哪一页，那就需要引入页号（其实是一个表空间的地址偏移量）。同时为了把这些数据页给关联起来，于是引入了前后指针，用于指向前后的页。这些都被加到了页头里。

页是需要读写的，16K说小也不小，写一半电源线被拔了也是有可能发生的，所以为了保证数据页的准确性，还引入了校验码。这个被加到了页尾。

那剩下的空间，才是用来放我们的record的。而record如果行数特别多的话，进入到页内时按个遍历，效率也不太行，所以为这些数据生成了一个页目录，具体实现不重要。只需要知道，它可以通过二分查找的方式将查找效率从O(n)变成O(lgn)。
在这里插入图片描述

从页到索引

如果想查一条record，我们可以把表空间里每一页都捞出来，在把里面的record捞出来挨个判断是不是我们要找的。

行数量小的时候，这么操作也没啥问题。

行数量大了，性能就慢了，于是为了加速搜索，我们可以在每一个数据页里选出主键id最小的record，而且只需要他们的主键id和所在页的页号，组成新的record，放入到一个新生成的一个数据页中，这个新数据页跟之前的页结构没啥区别，而且大小还是16K。

但为了更之前的数据页进行区分。数据页里加入了页层级（page level）的信息，从0开始往上算。于是页与页之间就有了上下层级的概念，就像下面这样：
在这里插入图片描述
页与页之间看起来就像一颗倒过来的树。也就是我们常说的B+树索引。

最下面那一层，page level 为 0,也就是所谓的叶子结点，其余都叫非叶子结点。

上面展示的是两层的树,如果数据变多了，我们还可以通过类似的方法，再往上构建一层。就成了三层的树。
在这里插入图片描述
这样我们就可以通过这样一颗B+树加速查询，举个例子。

比方我们要查找行数据5。会先从顶层页的record们入手，record里包含了主键id和页号（页地址）。看下图黄色箭头，向左最小id是1，向右最小id是7。那么id等于5的数据如果存在，必定在左边箭头。于是顺着record的页地址就到了6号数据页里，再判断id=5>4，所以肯定在右边的数据页里，于是加载105号数据页，在数据页里找到id=5的数据行，完成查询。

在这里插入图片描述
另外需要注意的是，上面的页的页号并不是连续的，他们在磁盘里也不一定是挨在一起的。