Mysql原理篇之表空间---05

Binary Oracle

已于 2022-10-25 21:33:31 修改

阅读量2.2k

点赞数 2

分类专栏： # MySql超神之路文章标签： mysql

于 2022-10-25 21:32:11 首次发布

原文链接：https://juejin.cn/book/6844733769996304392/section/6844733770050830344?scrollMenuIndex=0

版权

MySql超神之路专栏收录该内容

36 篇文章 12 订阅

订阅专栏

前言

通过前边儿的内容大家知道，表空间是一个抽象的概念，对于系统表空间来说，对应着文件系统中一个或多个实际文件；对于每个独立表空间来说，对应着文件系统中一个名为表名.ibd的实际文件。

在我们目前的认知中: 一个表的索引和数据信息由一颗聚簇索引树提供,这颗聚簇索引树每个节点都对应一个数据页，数据越多，树越高，节点越多，当前索引树占据数据页越多，而表空间就是负责管理当前表占用的一堆数据页的。

今天我们就来聊聊表空间是如何管理这一堆数据页的。

回顾

在正式开始之前，我们先来回顾一下之前的内容:

页面类型

InnoDB是以页为单位管理存储空间的，我们的聚簇索引（也就是完整的表数据）和其他的二级索引都是以B+树的形式保存到表空间的，而B+树的节点就是数据页。这个数据页的类型是：FIL_PAGE_INDEX，除了这种存放索引数据的页面类型之外，InnoDB也为了不同的目的设计了若干种不同类型的页面，为了唤醒大家的记忆，我们再一次把各种常用的页面类型提出来：

在这里插入图片描述
因为页面类型前边都有个FIL_PAGE或者FIL_PAGE_TYPE的前缀，为简便起见我们后边唠叨页面类型的时候就把这些前缀省略掉了，比方说FIL_PAGE_TYPE_ALLOCATED类型称为ALLOCATED类型，FIL_PAGE_INDEX类型称为INDEX类型。

页面通用部分

我们前边说过数据页，也就是INDEX类型的页由7个部分组成，其中的两个部分是所有类型的页面都通用的。当然我不能寄希望于你把我说的话都记住，所以在这里重新强调一遍，任何类型的页面都有下边这种通用的结构：

在这里插入图片描述
从上图中可以看出，任何类型的页都会包含这两个部分：

File Header：记录页面的一些通用信息
File Trailer：校验页是否完整，保证从内存到磁盘刷新时内容的一致性。

我们这里再强调一遍File Header的各个组成部分：

在这里插入图片描述
现在除了名称里边儿带有LSN的两个字段大家可能看不懂以外，其他的字段肯定都是倍儿熟了，不过我们仍要强调这么几点：

表空间中的每一个页都对应着一个页号，也就是FIL_PAGE_OFFSET，这个页号由4个字节组成，也就是32个比特位，所以一个表空间最多可以拥有2³²个页，如果按照页的默认大小16KB来算，一个表空间最多支持64TB的数据。表空间的第一个页的页号为0，之后的页号分别是1，2，3…依此类推
某些类型的页可以组成链表，链表中的页可以不按照物理顺序存储，而是根据FIL_PAGE_PREV和FIL_PAGE_NEXT来存储上一个页和下一个页的页号。需要注意的是，这两个字段主要是为了INDEX类型的页，也就是我们之前一直说的数据页建立B+树后，为每层节点建立双向链表用的，一般类型的页是不使用这两个字段的。
每个页的类型由FIL_PAGE_TYPE表示，比如像数据页的该字段的值就是0x45BF，我们后边会介绍各种不同类型的页，不同类型的页在该字段上的值是不同的。

独立表空间结构

我们知道InnoDB支持许多种类型的表空间，这里重点关注独立表空间和系统表空间的结构。它们的结构比较相似，但是由于系统表空间中额外包含了一些关于整个系统的信息，所以我们先挑简单一点的独立表空间来唠叨，稍后再说系统表空间的结构。

区（extent）的概念

表空间中的页实在是太多了，为了更好的管理这些页面，设计InnoDB的大叔们提出了区（英文名：extent）的概念。对于16KB的页来说，连续的64个页就是一个区，也就是说一个区默认占用1MB空间大小。不论是系统表空间还是独立表空间，都可以看成是由若干个区组成的，每256个区被划分成一组。画个图表示就是这样：
在这里插入图片描述
其中extent 0 ~ extent 255这256个区算是第一个组，extent 256 ~ extent 511这256个区算是第二个组，extent 512 ~ extent 767这256个区算是第三个组（上图中并未画全第三个组全部的区，请自行脑补），依此类推可以划分更多的组。这些组的头几个页面的类型都是类似的，就像这样：

在这里插入图片描述
从上图中我们能得到如下信息：

第一个组最开始的3个页面的类型是固定的，也就是说extent 0这个区最开始的3个页面的类型是固定的，分别是：

FSP_HDR类型：这个类型的页面是用来登记整个表空间的一些整体属性以及本组所有的区，也就是extent 0 ~ extent 255这256个区的属性，稍后详细唠叨。需要注意的一点是，整个表空间只有一个FSP_HDR类型的页面。
IBUF_BITMAP类型：这个类型的页面是存储本组所有的区的所有页面关于INSERT BUFFER的信息。当然，你现在不用知道啥是个INSERT BUFFER，后边会详细说到你吐。
INODE类型：这个类型的页面存储了许多称为INODE的数据结构，还是那句话，现在你不需要知道啥是个INODE，后边儿会说到你吐。

其余各组最开始的2个页面的类型是固定的，也就是说extent 256、extent 512这些区最开始的2个页面的类型是固定的，分别是：

XDES类型：全称是extent descriptor，用来登记本组256个区的属性，也就是说对于在extent 256区中的该类型页面存储的就是extent 256 ~ extent 511这些区的属性，对于在extent 512区中的该类型页面存储的就是extent 512 ~ extent 767这些区的属性。上边介绍的FSP_HDR类型的页面其实和XDES类型的页面的作用类似，只不过FSP_HDR类型的页面还会额外存储一些表空间的属性。
IBUF_BITMAP类型：上边介绍过了。

好了，宏观的结构介绍完了，里边儿的名词大家也不用记清楚，只要大致记得：表空间被划分为许多连续的区，每个区默认由64个页组成，每256个区划分为一组，每个组的最开始的几个页面类型是固定的就好了。

段（segment）的概念

为啥好端端的提出一个区（extent）的概念呢？我们以前分析问题的套路都是这样的：表中的记录存储到页里边儿，然后页作为节点组成B+树，这个B+树就是索引，然后吧啦吧啦一堆聚簇索引和二级索引的区别。这套路也没啥不妥的呀～

是的，如果我们表中数据量很少的话，比如说你的表中只有几十条、几百条数据的话，的确用不到区的概念，因为简单的几个页就能把对应的数据存储起来，但是你架不住表里的记录越来越多呀。

B+树的每一层中的页都会形成一个双向链表呀，File Header中的FIL_PAGE_PREV和FIL_PAGE_NEXT字段不就是为了形成双向链表设置的么？

从理论上说，不引入区的概念只使用页的概念对存储引擎的运行并没啥影响，但是我们来考虑一下下边这个场景：

我们每向表中插入一条记录，本质上就是向该表的聚簇索引以及所有二级索引代表的B+树的节点中插入数据。而B+树的每一层中的页都会形成一个双向链表，如果是以页为单位来分配存储空间的话，双向链表相邻的两个页之间的物理位置可能离得非常远。我们介绍B+树索引的适用场景的时候特别提到范围查询只需要定位到最左边的记录和最右边的记录，然后沿着双向链表一直扫描就可以了，而如果链表中相邻的两个页物理位置离得非常远，就是所谓的随机I/O。再一次强调，磁盘的速度和内存的速度差了好几个数量级，随机I/O是非常慢的，所以我们应该尽量让链表中相邻的页的物理位置也相邻，这样进行范围查询的时候才可以使用所谓的顺序I/O。

尽可能让每一层中用双向链表串联起来的页，在物理位置上也是相邻的。

所以，所以，所以才引入了区（extent）的概念，一个区就是在物理位置上连续的64个页。在表中数据量大的时候，为某个索引分配空间的时候就不再按照页为单位分配了，而是按照区为单位分配，甚至在表中的数据十分非常特别多的时候，可以一次性分配多个连续的区。虽然可能造成一点点空间的浪费（数据不足填充满整个区），但是从性能角度看，可以消除很多的随机I/O，功大于过嘛！

事情到这里就结束了么？太天真了，我们提到的范围查询，其实是对B+树叶子节点中的记录进行顺序扫描，而如果不区分叶子节点和非叶子节点，统统把节点代表的页面放到申请到的区中的话，进行范围扫描的效果就大打折扣了。所以设计InnoDB的大叔们对B+树的叶子节点和非叶子节点进行了区别对待，也就是说叶子节点有自己独有的区，非叶子节点也有自己独有的区。存放叶子节点的区的集合就算是一个段（segment），存放非叶子节点的区的集合也算是一个段。也就是说一个索引会生成2个段，一个叶子节点段，一个非叶子节点段。

默认情况下一个使用InnoDB存储引擎的表只有一个聚簇索引，一个索引会生成2个段，而段是以区为单位申请存储空间的，一个区默认占用1M存储空间，所以默认情况下一个只存了几条记录的小表也需要2M的存储空间么？以后每次添加一个索引都要多申请2M的存储空间么？这对于存储记录比较少的表简直是天大的浪费。设计InnoDB的大叔们都挺节俭的，当然也考虑到了这种情况。这个问题的症结在于到现在为止我们介绍的区都是非常纯粹的，也就是一个区被整个分配给某一个段，或者说区中的所有页面都是为了存储同一个段的数据而存在的，即使段的数据填不满区中所有的页面，那余下的页面也不能挪作他用。现在为了考虑以完整的区为单位分配给某个段对于数据量较小的表太浪费存储空间的这种情况，设计InnoDB的大叔们提出了一个碎片（fragment）区的概念，也就是在一个碎片区中，并不是所有的页都是为了存储同一个段的数据而存在的，而是碎片区中的页可以用于不同的目的，比如有些页用于段A，有些页用于段B，有些页甚至哪个段都不属于。碎片区直属于表空间，并不属于任何一个段。所以此后为某个段分配存储空间的策略是这样的：

在刚开始向表中插入数据的时候，段是从某个碎片区以单个页面为单位来分配存储空间的。
当某个段已经占用了32个碎片区页面之后，就会以完整的区为单位来分配存储空间。

当某个段占用的存储空间小于2/1个区大小的时候，就默认会在碎片区分配空间进行存储，如果大于2/1个区的话，就会以完整的区为单位进行分配。

所以现在段不能仅定义为是某些区的集合，更精确的应该是某些零散的页面以及一些完整的区的集合。除了索引的叶子节点段和非叶子节点段之外，InnoDB中还有为存储一些特殊的数据而定义的段，比如回滚段，当然我们现在并不关心别的类型的段，现在只需要知道段是一些零散的页面以及一些完整的区的集合就好了。

碎片区是为了节省空间和访问效率的折中方案

区的分类

通过上边一通唠叨，大家知道了表空间的是由若干个区组成的，这些区大体上可以分为4种类型：

空闲的区：现在还没有用到这个区中的任何页面。
有剩余空间的碎片区：表示碎片区中还有可用的页面。
没有剩余空间的碎片区：表示碎片区中的所有页面都被使用，没有空闲页面。
附属于某个段的区。每一个索引都可以分为叶子节点段和非叶子节点段，除此之外InnoDB还会另外定义一些特殊作用的段，在这些段中的数据量很大时将使用区来作为基本的分配单位。

这4种类型的区也可以被称为区的4种状态（State），设计InnoDB的大叔们为这4种状态的区定义了特定的名词儿：

在这里插入图片描述
需要再次强调一遍的是，处于FREE、FREE_FRAG以及FULL_FRAG这三种状态的区都是独立的，算是直属于表空间；而处于FSEG状态的区是附属于某个段的。

碎片区内存放的都是一些占用存储空间小于2/1区大小的段，因此碎片区内可能会与多个段关联，因此碎片区是属于表空间的，而非被某个段完全占用。

为了方便管理这些区，设计InnoDB的大叔设计了一个称为XDES Entry的结构（全称就是Extent Descriptor Entry），每一个区都对应着一个XDES Entry结构，这个结构记录了对应的区的一些属性。我们先看图来对这个结构有个大致的了解：

在这里插入图片描述
从图中我们可以看出，XDES Entry是一个40个字节的结构，大致分为4个部分，各个部分的释义如下：

Segment ID（8字节）

每一个段都有一个唯一的编号，用ID表示，此处的Segment ID字段表示就是该区所在的段。当然前提是该区已经被分配给某个段了，不然的话该字段的值没啥意义。
List Node（12字节）

这个部分可以将若干个XDES Entry结构串联成一个链表，大家看一下这个List Node的结构：

在这里插入图片描述

索引树上每一层的页都是通过双向链表串联起来的，一个表空间下可能会存在多个区，同样也可以采用双向链表串联。

如果我们想定位表空间内的某一个位置的话，只需指定页号以及该位置在指定页号中的页内偏移量即可。所以：
- Pre Node Page Number和Pre Node Offset的组合就是指向前一个XDES Entry的指针
- Next Node Page Number和Next Node Offset的组合就是指向后一个XDES Entry的指针。
把一些XDES Entry结构连成一个链表有啥用？稍安勿躁，我们稍后唠叨XDES Entry结构组成的链表问题。
State（4字节）

这个字段表明区的状态。可选的值就是我们前边说过的那4个，分别是：FREE、FREE_FRAG、FULL_FRAG和FSEG。具体释义就不多唠叨了，前边说的够仔细了。
Page State Bitmap（16字节）

这个部分共占用16个字节，也就是128个比特位。我们说一个区默认有64个页，这128个比特位被划分为64个部分，每个部分2个比特位，对应区中的一个页。比如Page State Bitmap部分的第1和第2个比特位对应着区中的第1个页面，第3和第4个比特位对应着区中的第2个页面，依此类推，Page State Bitmap部分的第127和128个比特位对应着区中的第64个页面。这两个比特位的第一个位表示对应的页是否是空闲的，第二个比特位还没有用。

bitmap可以看做是页位图，用来记录当前区内页面的使用状态，这一点和操作系统文件系统中块位图和Inode位图思想一致。

整理

上面吧啦吧啦了那么多，继续下面内容之前，我们先来把思路整理一下:

Innodb提供的聚簇索引叶子层存放了完整的用户记录数据，叶子层每一个节点都对应一个数据页，叶子层数据页通过双向链表串联了起来。

在进行范围查询的时候，需要先定位好最大和最小范围:

在这里插入图片描述
然后，需要扫描这个范围内所有的数据页，那么如果这些数据页在物理内存上的离散程度很大，那么就意味着会产生很多的随机IO。

一会需要移动磁臂到磁道1，下一个数据页又要移动磁臂到磁道五，这样的开销是非常大滴老兄！磁盘读取相关知识

因此，如果我们能够尽可能让同一层上数据页在物理位置上尽可能相邻，那么就可以减少随机IO带来的性能损耗，

操作系统层面也有对应的处理，就是让相邻的扇区尽量排列在同一个磁道上，从而减少寻道带来的性能损耗。

如何让这些数据页尽可能相邻呢？

找一块固定大小空间专门用来存放当前索引树，每当当前索引树需要分配一块新的数据页时，就从这块空间申请一个空闲内存页，这样就能确保分配的数据页之间在物理空间上是相邻的，这个固定大小的空间就称为区，一个区掌管着64个空闲页。

索引树分为目录层和叶子层，如果让目录层和叶子层都挤在一个区中存放，那么查询的时候就会不太方便，因此采用叶子层和目录层分离的方式来进行存储，叶子层单独分配一个区进行存储，而目录层也单独分配一个区进行存放。

由于叶子层和目录层可能需要不只一个区的大小来存储数据，因此叶子层的区集合称为叶子节点段，目录层的区集合称为目录段。

最后，为了优化给一个小表的叶子段和目录段直接分配一个完整区带来的空间浪费问题，于是引入了碎片区概念。

操作系统对于内存的管理也是按照页进行的，引入页的原因很大程度也是为了减少内存碎片，虽然也存在一个页只存放很少数据，从而造成当前页大部分存储空间浪费的现象，但是并没有引入碎片页的概念，可能是因为这样做会增加内存管理模块的复杂度，而Innodb由于也是以页作为最小分配单位，所以也存在上述问题，但是浪费一页空间还可以忍受，而浪费一个区的空间就难以忍受了，毕竟有64个页的大小，因此才有了碎片区的出现。

XDES Entry链表

经过上面的讲述，相信各位已经明白了区和段存在的意义是什么，以及为什么要有碎片区的存在，那么我们这里再回到最初的起点，捋一捋向某个段中插入数据的过程：

当段中数据较少的时候，首先会查看表空间中是否有状态为FREE_FRAG的区，也就是找还有空闲空间的碎片区，如果找到了，那么从该区中取一些零散的页把数据插进去；否则到表空间下申请一个状态为FREE的区，也就是空闲的区，把该区的状态变为FREE_FRAG，然后从该新申请的区中取一些零散的页把数据插进去。之后不同的段使用零散页的时候都会从该区中取，直到该区中没有空闲空间，然后该区的状态就变成了FULL_FRAG。

现在的问题是你怎么知道表空间里的哪些区是FREE的，哪些区的状态是FREE_FRAG的，哪些区是FULL_FRAG的？要知道表空间的大小是可以不断增大的，当增长到GB级别的时候，区的数量也就上千了，我们总不能每次都遍历这些区对应的XDES Entry结构吧？这时候就是XDES Entry中的List Node部分发挥奇效的时候了，我们可以通过List Node中的指针，做这么三件事：

把状态为FREE的区对应的XDES Entry结构通过List Node来连接成一个链表，这个链表我们就称之为FREE链表。
把状态为FREE_FRAG的区对应的XDES Entry结构通过List Node来连接成一个链表，这个链表我们就称之为FREE_FRAG链表。
把状态为FULL_FRAG的区对应的XDES Entry结构通过List Node来连接成一个链表，这个链表我们就称之为FULL_FRAG链表。

这样每当我们想找一个FREE_FRAG状态的区时，就直接把FREE_FRAG链表的头节点拿出来，从这个节点中取一些零散的页来插入数据，当这个节点对应的区用完时，就修改一下这个节点的State字段的值，然后从FREE_FRAG链表中移到FULL_FRAG链表中。同理，如果FREE_FRAG链表中一个节点都没有，那么就直接从FREE链表中取一个节点移动到FREE_FRAG链表的状态，并修改该节点的STATE字段值为FREE_FRAG，然后从这个节点对应的区中获取零散的页就好了。

这里的FREE区和碎片区相关的FREE_FRAG区和FULL_FRAG区都直属于表空间管理，因此上述三个链表与具体的段无关。

当段中数据已经占满了32个零散的页后，就直接申请完整的区来插入数据了。

我们知道一个段是由多个区组成的，那么某个段下的区也可以分为三种状态，如下图所示:
在这里插入图片描述
现在，我们眼前面临的问题有如下几个:

如何快速区分出哪些区属于哪个段呢?
如何管理某个段下三种不同状态区组成的集合呢？

区的状态如果为FSEG，那么表明当前区是属于某个段下的，并且如果某个区的状态为FSEG，那么我们就可以根据提供当前区信息的XDES Entry中获取到当前区从属的段ID。

为了快速得到属于当前段的区有哪些，我们可以根据段号来建立链表，如果直接粗暴的将所有属于当前段的区串联为一个单链表，那么就无法很好的区分出上面给出某个段下三种区状态集合。

因此仿照表空间对区的分类管理，我们也可以对每个段建立如下三种状态的链表集合:

FREE链表：同一个段中，所有页面都是空闲的区对应的XDES Entry结构会被加入到这个链表。注意和直属于表空间的FREE链表区别开了，此处的FREE链表是附属于某个段的。
NOT_FULL链表：同一个段中，仍有空闲空间的区对应的XDES Entry结构会被加入到这个链表。
FULL链表：同一个段中，已经没有空闲空间的区对应的XDES Entry结构会被加入到这个链表。

在这里插入图片描述
再次强调一遍，每一个索引都对应两个段，每个段都会维护上述的3个链表，比如下边这个表：

CREATE TABLE t (
    c1 INT NOT NULL AUTO_INCREMENT,
    c2 VARCHAR(100),
    c3 VARCHAR(100),
    PRIMARY KEY (c1),
    KEY idx_c2 (c2)
)ENGINE=InnoDB;

这个表t共有两个索引，一个聚簇索引，一个二级索引idx_c2，所以这个表共有4个段，每个段都会维护上述3个链表，总共是12个链表，加上我们上边说过的直属于表空间的3个链表，整个独立表空间共需要维护15个链表。所以段在数据量比较大时插入数据的话，会先获取NOT_FULL链表的头节点，直接把数据插入这个头节点对应的区中即可，如果该区的空间已经被用完，就把该节点移到FULL链表中。

链表基节点

上边光是介绍了一堆链表，可我们怎么找到这些链表呢，或者说怎么找到某个链表的头节点或者尾节点在表空间中的位置呢？设计InnoDB的大叔当然考虑了这个问题，他们设计了一个叫List Base Node的结构，翻译成中文就是链表的基节点。这个结构中包含了链表的头节点和尾节点的指针以及这个链表中包含了多少节点的信息，我们画图看一下这个结构的示意图：

在这里插入图片描述
我们上边介绍的每个链表都对应这么一个List Base Node结构，其中：

List Length表明该链表一共有多少节点，
First Node Page Number和First Node Offset表明该链表的头节点在表空间中的位置。
Last Node Page Number和Last Node Offset表明该链表的尾节点在表空间中的位置。

一般我们把某个链表对应的List Base Node结构放置在表空间中固定的位置，这样想找定位某个链表就变得so easy啦。

链表小结

综上所述，表空间是由若干个区组成的，每个区都对应一个XDES Entry的结构，直属于表空间的区对应的XDES Entry结构可以分成FREE、FREE_FRAG和FULL_FRAG这3个链表；每个段可以附属若干个区，每个段中的区对应的XDES Entry结构可以分成FREE、NOT_FULL和FULL这3个链表。每个链表都对应一个List Base Node的结构，这个结构里记录了链表的头、尾节点的位置以及该链表中包含的节点数。正是因为这些链表的存在，管理这些区才变成了一件so easy的事情。

段的结构

我们前边说过，段其实不对应表空间中某一个连续的物理区域，而是一个逻辑上的概念，由若干个零散的页面以及一些完整的区组成。像每个区都有对应的XDES Entry来记录这个区中的属性一样，设计InnoDB的大叔为每个段都定义了一个INODE Entry结构来记录一下段中的属性。大家看一下示意图：

在这里插入图片描述

它的各个部分释义如下：

Segment ID

就是指这个INODE Entry结构对应的段的编号（ID）。
NOT_FULL_N_USED

这个字段指的是在NOT_FULL链表中已经使用了多少个页面。
3个List Base Node

分别为段的FREE链表、NOT_FULL链表、FULL链表定义了List Base Node，这样我们想查找某个段的某个链表的头节点和尾节点的时候，就可以直接到这个部分找到对应链表的List Base Node。so easy!
Magic Number：

这个值是用来标记这个INODE Entry是否已经被初始化了（初始化的意思就是把各个字段的值都填进去了）。如果这个数字是值的97937874，表明该INODE Entry已经初始化，否则没有被初始化。（不用纠结这个值有啥特殊含义，人家规定的）。
Fragment Array Entry

我们前边强调过无数次段是一些零散页面和一些完整的区的集合，每个Fragment Array Entry结构都对应着一个零散的页面，这个结构一共4个字节，表示一个零散页面的页号。

结合着这个INODE Entry结构，大家可能对段是一些零散页面和一些完整的区的集合的理解再次深刻一些。

INODE Entry负责整合当前段拥有的资源和状态信息记录，那么大家思考一下: 一个独立表空间可能会存在多个段，每个段都对应一个INODE Entry,那么表空间按照道理也应该套娃式提供一个地方来存放这些INODE Entry资源信息和其他资源信息，以及自身状态信息记录等，mysql有没有这样做呢？ —> 接着往下看就晓得了

各类型页面详细情况

到现在为止我们已经大概清楚了表空间、段、区、XDES Entry、INODE Entry、各种以XDES Entry为节点的链表的基本概念了，可是总有一种飞在天上不踏实的感觉，每个区对应的XDES Entry结构到底存储在表空间的什么地方？直属于表空间的FREE、FREE_FRAG、FULL_FRAG链表的基节点到底存储在表空间的什么地方？每个段对应的INODE Entry结构到底存在表空间的什么地方？我们前边介绍了每256个连续的区算是一个组，想解决刚才提出来的这些个疑问还得从每个组开头的一些类型相同的页面说起，接下来我们一个页面一个页面的分析，真相马上就要浮出水面了。

FSP_HDR类型

在这里插入图片描述

首先看第一个组的第一个页面，当然也是表空间的第一个页面，页号为0。这个页面的类型是FSP_HDR，它存储了表空间的一些整体属性以及第一个组内256个区的对应的XDES Entry结构，直接看这个类型的页面的示意图：

在这里插入图片描述
从图中可以看出，一个完整的FSP_HDR类型的页面大致由5个部分组成，各个部分的具体释义如下表：

在这里插入图片描述
File Header和File Trailer就不再强调了，另外的几个部分中，Empty Space是尚未使用的空间，我们不用管它，重点来看看File Space Header和XDES Entry这两个部分。

File Space Header部分

从名字就可以看出来，这个部分是用来存储表空间的一些整体属性的，废话少说，看图：

在这里插入图片描述
哇唔，字段有点儿多哦，不急一个一个慢慢看。下面是各个属性的简单描述：

在这里插入图片描述

这里头的Space ID、Not Used、Size这三个字段大家肯定一看就懂，其他的字段我们再详细瞅瞅，为了大家的阅读体验，我就不严格按照实际的字段顺序来解释各个字段了哈。

List Base Node for FREE List、List Base Node for FREE_FRAG List、List Base Node for FULL_FRAG List。

这三个大家看着太亲切了，分别是直属于表空间的FREE链表的基节点、FREE_FRAG链表的基节点、FULL_FRAG链表的基节点，这三个链表的基节点在表空间的位置是固定的，就是在表空间的第一个页面（也就是FSP_HDR类型的页面）的File Space Header部分。所以之后定位这几个链表就so easy啦。

在这里插入图片描述

FRAG_N_USED

这个字段表明在FREE_FRAG链表中已经使用的页面数量。

FREE Limit

我们知道表空间都对应着具体的磁盘文件，一开始我们创建表空间的时候对应的磁盘文件中都没有数据，所以我们需要对表空间完成一个初始化操作，包括为表空间中的区建立XDES Entry结构，为各个段建立INODE Entry结构，建立各种链表吧啦吧啦的各种操作。我们可以一开始就为表空间申请一个特别大的空间，但是实际上有绝大部分的区是空闲的，我们可以选择把所有的这些空闲区对应的XDES Entry结构加入FREE链表，也可以选择只把一部分的空闲区加入FREE链表，等啥时候空闲链表中的XDES Entry结构对应的区不够使了，再把之前没有加入FREE链表的空闲区对应的XDES Entry结构加入FREE链表，中心思想懒加载，设计InnoDB的大叔采用的就是后者，他们为表空间定义了FREE Limit这个字段，在该字段表示的页号之前的区都被初始化了，之后的区尚未被初始化。

Next Unused Segment ID

表中每个索引都对应2个段，每个段都有一个唯一的ID，那当我们为某个表新创建一个索引的时候，就意味着要创建两个新的段。那怎么为这个新创建的段找一个唯一的ID呢？去遍历现在表空间中所有的段么？我们说过，遍历是不可能遍历的，这辈子都不可能遍历，所以设计InnoDB的大叔们提出了这个名叫Next Unused Segment ID的字段，该字段表明当前表空间中最大的段ID的下一个ID，这样在创建新段的时候赋予新段一个唯一的ID值就so easy啦，直接使用这个字段的值就好了。

Space Flags

表空间对于一些布尔类型的属性，或者只需要寥寥几个比特位搞定的属性都放在了这个Space Flags中存储，虽然它只有4个字节，32个比特位大小，却存储了好多表空间的属性，详细情况如下表：

在这里插入图片描述

List Base Node for SEG_INODES_FULL List和List Base Node for SEG_INODES_FREE List

每个段对应的INODE Entry结构会集中存放到一个类型为INODE的页中，如果表空间中的段特别多，则会有多个INODE Entry结构，可能一个页放不下，这些INODE类型的页会组成两种列表：

SEG_INODES_FULL链表，该链表中的INODE类型的页面都已经被INODE Entry结构填充满了，没空闲空间存放额外的INODE Entry了。
SEG_INODES_FREE链表，该链表中的INODE类型的页面仍有空闲空间来存放INODE Entry结构。

由于我们现在还没有详细唠叨INODE类型页，所以等会说过INODE类型的页之后再回过头来看着两个链表。

Mysql大叔值得借鉴的做法: 为了区分元素的状态，而选择采用不同的链表存放不同状态的元素，并在进行状态转换时，将元素移动到对应的链表中存放。

XDES Entry部分

紧接着File Space Header部分的就是XDES Entry部分了，我们嘴上唠叨过无数次，却从没见过真身的XDES Entry就是在表空间的第一个页面中保存的。我们知道一个XDES Entry结构的大小是40字节，但是一个页面的大小有限，只能存放有限个XDES Entry结构，所以我们才把256个区划分成一组，在每组的第一个页面中存放256个XDES Entry结构。大家回看那个FSP_HDR类型页面的示意图，XDES Entry 0就对应着extent 0，XDES Entry 1就对应着extent 1… 依此类推，XDES Entry255就对应着extent 255。

因为每个区对应的XDES Entry结构的地址是固定的，所以我们访问这些结构就so easy啦，至于该结构的详细使用情况我们已经唠叨的够明白了，在这就不赘述了。

XDES类型

我们说过，每一个XDES Entry结构对应表空间的一个区，虽然一个XDES Entry结构只占用40字节，但你抵不住表空间的区的数量也多啊。在区的数量非常多时，一个单独的页可能就不够存放足够多的XDES Entry结构，所以我们把表空间的区分为了若干个组，每组开头的一个页面记录着本组内所有的区对应的XDES Entry结构。由于第一个组的第一个页面有些特殊，因为它也是整个表空间的第一个页面，所以除了记录本组中的所有区对应的XDES Entry结构以外，还记录着表空间的一些整体属性，这个页面的类型就是我们刚刚说完的FSP_HDR类型，整个表空间里只有一个这个类型的页面。除去第一个分组以外，之后的每个分组的第一个页面只需要记录本组内所有的区对应的XDES Entry结构即可，不需要再记录表空间的属性了，为了和FSP_HDR类型做区别，我们把之后每个分组的第一个页面的类型定义为XDES，它的结构和FSP_HDR类型是非常相似的：

在这里插入图片描述
与FSP_HDR类型的页面对比，除了少了File Space Header部分之外，也就是除了少了记录表空间整体属性的部分之外，其余的部分是一样一样的。由于我们上边唠叨的已经够仔细了，对于XDES类型的页面也就不重复唠叨了哈。

IBUF_BITMAP类型

对比前边介绍表空间的图，每个分组的第二个页面的类型都是IBUF_BITMAP，这种类型的页里边记录了一些有关Change Buffer的东东，由于这个Change Buffer里又包含了贼多的概念，考虑到大家在一章中接受这么多新概念有点呼吸不适，怕大家心脏病犯了所以就把Change Buffer的相关知识放到后边的章节中，大家稍安勿躁哈。

INODE类型

再次对比前边介绍表空间的图，第一个分组的第三个页面的类型是INODE。我们前边说过设计InnoDB的大叔为每个索引定义了两个段，而且为某些特殊功能定义了些特殊的段。为了方便管理，他们又为每个段设计了一个INODE Entry结构，这个结构中记录了关于这个段的相关属性。而我们这会儿要介绍的这个INODE类型的页就是为了存储INODE Entry结构而存在的。好了，废话少说，直接看图：

在这里插入图片描述
从图中可以看出，一个INODE类型的页面是由这几部分构成的：

在这里插入图片描述
除了File Header、Empty Space、File Trailer这几个老朋友外，我们重点关注List Node for INODE Page List和INODE Entry这两个部分。

首先看INODE Entry部分，我们前边已经详细介绍过这个结构的组成了，主要包括对应的段内零散页面的地址以及附属于该段的FREE、NOT_FULL和FULL链表的基节点。每个INODE Entry结构占用192字节，一个页面里可以存储85个这样的结构。

重点看一下List Node for INODE Page List这个玩意儿，因为一个表空间中可能存在超过85个段，所以可能一个INODE类型的页面不足以存储所有的段对应的INODE Entry结构，所以就需要额外的INODE类型的页面来存储这些结构。还是为了方便管理这些INODE类型的页面，设计InnoDB的大叔们将这些INODE类型的页面串联成两个不同的链表：

SEG_INODES_FULL链表：该链表中的INODE类型的页面中已经没有空闲空间来存储额外的INODE Entry结构了。
SEG_INODES_FREE链表：该链表中的INODE类型的页面中还有空闲空间来存储额外的INODE Entry结构了。

想必大家已经认出这两个链表了，我们前边提到过这两个链表的基节点就存储在File Space Header里边，也就是说这两个链表的基节点的位置是固定的，所以我们可以很轻松的访问到这两个链表。以后每当我们新创建一个段（创建索引时就会创建段）时，都会创建一个INODE Entry结构与之对应，存储INODE Entry的大致过程就是这样的：

先看看SEG_INODES_FREE链表是否为空，如果不为空，直接从该链表中获取一个节点，也就相当于获取到一个仍有空闲空间的INODE类型的页面，然后把该INODE Entry结构放到该页面中。当该页面中无剩余空间时，就把该页放到SEG_INODES_FULL链表中。
如果SEG_INODES_FREE链表为空，则需要从表空间的FREE_FRAG链表中申请一个页面，修改该页面的类型为INODE，把该页面放到SEG_INODES_FREE链表中，与此同时把该INODE Entry结构放入该页面。

Segment Header 结构的运用

我们知道一个索引会产生两个段，分别是叶子节点段和非叶子节点段，而每个段都会对应一个INODE Entry结构，那我们怎么知道某个段对应哪个INODE Entry结构呢？所以得找个地方记下来这个对应关系。希望你还记得我们在唠叨数据页，也就是INDEX类型的页时有一个Page Header部分，当然我不能指望你记住，所以把Page Header部分再抄一遍给你看：

Page Header部分（为突出重点，省略了好多属性）、

在这里插入图片描述
其中的PAGE_BTR_SEG_LEAF和PAGE_BTR_SEG_TOP都占用10个字节，它们其实对应一个叫Segment Header的结构，该结构图示如下：

各个部分的具体释义如下：

在这里插入图片描述
这样子就很清晰了，PAGE_BTR_SEG_LEAF记录着叶子节点段对应的INODE Entry结构的地址是哪个表空间的哪个页面的哪个偏移量，PAGE_BTR_SEG_TOP记录着非叶子节点段对应的INODE Entry结构的地址是哪个表空间的哪个页面的哪个偏移量。这样子索引和其对应的段的关系就建立起来了。不过需要注意的一点是，因为一个索引只对应两个段，所以只需要在索引的根页面中记录这两个结构即可。

真实表空间对应的文件大小

等会儿等会儿，上边的这些概念已经压的快喘不过气了。不过独立表空间有那么大么？我到数据目录里看了，一个新建的表对应的.ibd文件只占用了96K，才6个页面大小，上边的内容该不是扯犊子吧？

哈，一开始表空间占用的空间自然是很小，因为表里边都没有数据嘛！不过别忘了这些.ibd文件是自扩展的，随着表中数据的增多，表空间对应的文件也逐渐增大。

小结

到此，关于表空间前半部分独立表空间的内容基本就叙述完了，相信各位在第一次看的时候已经被绕晕了，那么就跟随我的步伐，来重头简单梳理一下流程吧:

索引树由目录层(有多层)和叶子层(一层)组成，每一层的数据页内部和用双向链表串联起来的数据页之间都是按照索引列进行有序排列。
当我们需要遍历用双向链表串联起来的数据页时，如果链表上相邻数据页在物理位置上不相邻，那么会产生大量随机IO，从而在范围查询这种场景下导致极低的遍历效率。
为了尽量让同一层用双向链表串联起来的数据页不仅在逻辑上相邻，并且物理页上也相邻,那么我们可以划分出一块物理区域单独用于分配给当前层使用，这块固定区域被称作区，一个区由64个页大小组成。
索引树分为目录层和叶子层，如果让目录层和叶子层都挤在一个区中存放，那么查询的时候就会不太方便，因此采用叶子层和目录层分离的方式来进行存储，叶子层单独分配一个区进行存储，而目录层也单独分配一个区进行存放。
由于叶子层和目录层可能需要不只一个区的大小来存储数据，因此叶子层的区集合称为叶子节点段，目录层的区集合称为目录段。
最后，为了优化给一个小表的叶子段和目录段直接分配一个完整区带来的空间浪费问题，于是引入了碎片区。
为了管理好处于不同状态的区集合，表空间采用了三条链表，每一条链表上单独存放一种状态的区集合
同样段为了管理了处于不同状态的区集合，也采用了三条链表，每一条链表上单独存放一种状态的区集合(这里不清楚还是需要回看上面)。
表空间下会存在多个段，表空间为了管理这些段，给每个段都弄了个INODE Entry记录每个段的信息，INODE Entry中保存了当前段管理的三条链表的基节点和零散页面集合。
由于表空间下可能会存在很多区，因此采用每256个区为一组的方式进行区划分管理，而在第一组的第一个页面中记录了当前表空间的一些信息和当前组256个区的信息。
其他组的第一个页面中主要负责保存的就只有当前组的256个区的信息。
第一组的第三个页面是INODE类型的页面，主要负责保存当前表空间下所有INODE信息，一个INODE记录的就是一个段的信息。
每个索引树上的根页面都记录着叶子节点段和非叶子节点段对应的INODE是哪一个，即建立好段和INODE的映射关系。

下一篇文章我们将来讲述表空间的下半部分: 系统表空间。

本篇文章整理至从根上理解Mysql,对其中内容作出了些许补充

Binary Oracle

关注

2
点赞
踩
9

收藏

觉得还不错? 一键收藏
0
评论
Mysql原理篇之表空间---05

通过前边儿的内容大家知道，表空间是一个抽象的概念，对于系统表空间来说，对应着文件系统中一个或多个实际文件；对于每个独立表空间来说，对应着文件系统中一个名为表名.ibd的实际文件。在我们目前的认知中: 一个表的索引和数据信息由一颗聚簇索引树提供,这颗聚簇索引树每个节点都对应一个数据页，数据越多，树越高，节点越多，当前索引树占据数据页越多，而表空间就是负责管理当前表占用的一堆数据页的。今天我们就来聊聊表空间是如何管理这一堆数据页的。
复制链接

扫一扫