概述
表空间是一个在 InnoDB 中比较抽象的概念，对于系统表空间来说，对应着文件系统中一个或多个实际文件；而对于每个独立表空间来说，对应着文件系统中一个名为表名.ibd 的实际文件。可以把表空间想象成由很多个页组成的池子（pool），当我们想为某个表插入一条记录的时候，就会从对应的池子中选一个合适的页将数据写进去。
Innodb中的页
页面类型
InnoDB是以页为单位管理存储空间的，我们的聚簇索引（也就是完整的表数据）和其他的二级索引都是以 B+ 树的形式保存到表空间的，而 B+ 树的节点就是数据页。数据页的类型名使用字段FIL_PAGE_INDEX（简写为INDEX）表示 ，除了这种存放索引数据的页面类型之外，InnoDB也为了不同的用途设计了很多其他类型的页面。如allocation（未分配页）、undo_log（undo日志页）、redo_log 等。
页面通用部分
前边说过数据页，也就是 INDEX 类型的页由7个部分组成，其中的两个部分File Header 和 File Trailer是所有类型页面都通用的。如下，任何类型的页面都有下边这种通用的结构：
从上图中可以看出，任何类型的页都会包含这两个部分：
- File Header ：记录页面的一些通用信息
- File Trailer ：校验页是否完整，保证从内存到磁盘刷新时内容的一致性。
File Header 的各个组成部分如下：
| 名称 | 占用空间大学 | 说明 |
|---|---|---|
| FIL_PAGE_SPACE_OR_CHKSUM | 4 字节 | 页的校验和（checksum值） |
| FIL_PAGE_OFFSET | 4 字节 | 页号 |
| FIL_PAGE_PREV | 4 字节 | 上一个页的页号 |
| FIL_PAGE_NEXT | 4 字节 | 下一个页的页号 |
| FIL_PAGE_LSN | 8 字节 | 页面被最后修改时对应的日志序列位置（英文名是：Log Sequence Number） |
| FIL_PAGE_TYPE | 2 字节 | 该页的类型 |
| FIL_PAGE_FILE_FLUSH_LSN | 8 字节 | 仅在系统表空间的一个页中定义，代表文件至少被刷新到了对应的LSN值 |
| FIL_PAGE_ARCH_LOG_NO_OR_SPACE_ID | 4 字节 | 页属于哪个表空间 |
说明几点：
- 表空间中的每一个页都有一个页号，也就是 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 的信息 ，后边会详细说这个类型。
- 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 类型作用类似，只不过 FSP_HDR 类型的页面还会额外存储一些表空间的属性。**
- IBUF_BITMAP 类型：如上。
总结：表空间被划分为许多连续的区 ，每个区默认由64个页组成，每256个区划分为一组，每个组的最开始的几个页面类型是固定的。
段（segment）的概念
如果我们表中数据量很少的话，用一页或者几页可能就可以将数据全部存储，完全用不到区的概念，但如果表里的记录越来越多呢？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个碎片区页面之后，就会以完整的区为单位来分配存储空间。
所以现在段不能仅定义为是某些区的集合，更精确的应该是某些零散的页面以及一些完整的区的集合。除了索引的叶子节点段和非叶子节点段之外， InnoDB 中还有为存储一些特殊的数据而定义的段，比如回滚段等等。
区的分类
从上面我们知道表空间的是由若干个区组成的，这些区大体上可以分为4种类型:
- 空闲的区:现在还没有用到这个区中的任何页面。
- 有剩余空间的碎片区:表示碎片区中还有可用的页面。
- 没有剩余空间的碎片区:表示碎片区中的所有页面都被使用，没有空闲页面。
- 附属于某个段的区。每一个索引都可以分为叶子节点段和非叶子节点段，除此之外InnoDB还会另外定义一些 特殊作用的段，在这些段中的数据量很大时将使用区来作为基本的分配单位。（可以理解为该区全部储存的某个段的数据）
这4种类型的区也可以被称为区的4种状态( State )，如下：
| 状态名 | 含义 |
|---|---|
| FREE | 空闲的区 |
| FREE_FRAG | 有剩余空间的碎片区 |
| FULL_FRAG | 没有剩余空间的碎片区 |
| FSEG | 附属于某个段的区 |
说明：处于 FREE 、 FREE_FRAG 以及 FULL_FRAG 这三种状态的区都是独立的，算是直属于表空间；而处于 FSEG状态的区是附属于某个段的。如果把表空间比作是一个集团军，段就相当于师，区就相当于团。一般的团都是隶属于某个师的，就像处于FSEG的区（团）全都隶属于某个段（师），而处于FREE、FREE_FRAG以及FULL_FRAG这三种状态的区却直接隶属于表空间，就像独立团直接听命于军部一样。
为了方便管理这些区，设计 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 结构（管理区的）连成一个链表，而每个链表对应的 List Base Node 结构放置在表空间中的固定位置，这样就可以很容易地定位某个链表了。
- 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个页面。这两个比特位的第一个位表示对应的页是否是空闲的，第二个比特位还没有用。
XDES Entry链表
上面我们已经了解了很多新的概念，包括区、段、碎片区、附属于段的区、 XDES Entry 结构等等，提出这些概念的目的一方面是想提高向表插入数据的效率，同时在数据量少的时候减少表空间的浪费。现在我们知道向表中插入数据本质上就是向表中各个索引的叶子节点段、非叶子节点段插入数据，也知道区有不同的状态。下面我们想一想向某个段中插入数据的过程：
- 当段中数据较少的时候，首先会查看表空间中是否有状态为 FREE_FRAG 的区，也就是找还有空闲空间的碎片区，如果找到了，那么从该区中取一些零碎的页把数据插进去；否则到表空间下申请一个状态为 FREE 的区，也就是空闲的区，把该区的状态变为 FREE_FRAG ，然后从该新申请的区中取一些零碎的页把数据插进去。之后不同的段使用零碎页的时候都会从该区中取，直到该区中没有空闲空间，然后该区的状态就变成了FULL_FRAG 。
现在的问题是如何区分表空间中的哪些区是 FREE 的，哪些区的状态是 FREE_FRAG 的，哪些区是FULL_FRAG 的？要知道当记录数很多时区的数量也就很多，每次都要遍历这些区对应的 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 ，然后从这个节点对应的区中获取零碎的页就可以使用了。
- 当段中数据已经占满了32个零散的页后，就直接申请完整的区来插入数据了。
那么我们怎么知道哪些区属于哪个段的呢？当然是使用链表。我们按段使用不同的链表，有多少个段就建多少个链表，并根据使用状态进行细分。InnoDB 中为每个段中的区对应的 XDES Entry 结构建立了三个链表： - 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+6n个链表 其中n为索引数量），加上我们上边说过的直属于表空间的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 结构放置在表空间中固定的位置，这样想找定位某个链表就很简单了。
链表小结
综上所述，表空间（我们一般都为每个表分配了一个独立的表空间）是由若干个区组成的，每个区都对应一个 XDES Entry 的结构，直属于表空间的区对应的 XDESEntry 结构可以分成 FREE 、 FREE_FRAG 和 FULL_FRAG 这3个链表；每个段可以附属若干个区，每个段中的区对应的 XDES Entry 结构可以分成 FREE 、 NOT_FULL 和 FULL 这3个链表。每个链表都对应一个 List Base Node 的结构，这个结构里记录了链表的头、尾节点的位置以及该链表中包含的节点数。通过这些链表的存在，很容易地就可以管理这些区。
段的结构
段其实不对应表空间中某一个连续的物理区域，而是一个逻辑上的概念，由若干个零散的页面以及一些完整的区组成。像每个区都有对应的 XDES Entry 来记录这个区中的属性一样，InnoDB 中为每个段都定义了一个 INODE Entry 结构来记录一下段中的属性。如下图所示：
说明如下：
- Segment ID
- 就是指这个 INODE Entry 结构对应的段的编号（ID）。
NOT_FULL_N_USED
这个字段指的是在 NOT_FULL 链表中已经使用了多少个页面。下次从 NOT_FULL 链表分配空闲页面时可以直接根据这个字段的值定位到。而不用从链表中的第一个页面开始遍历着寻找空闲页面。 - 3个 List Base Node
分别为段的 FREE 链表、 NOT_FULL 链表、 FULL 链表定义了 List Base Node ，这样我们想查找某个段的某个链表的头节点和尾节点的时候，就可以直接到这个部分找到对应链表的 List Base Node 。 - Magic Number ：
这个值是用来标记这个 INODE Entry 是否已经被初始化了（初始化的意思就是把各个字段的值都填进去了）。如果这个数字是值的 97937874 ，表明该 INODE Entry 已经初始化，否则没有被初始化。（这个书数字就是规定的）。 - Fragment Array Entry
我们知道段是一些零散页面和一些完整的区的集合，每个 Fragment Array Entry 结构都对应着一个零散的页面，这个结构一共4个字节，表示一个零散页面的页号。
各类型页面详细情况
FSP_ HDR 类型
首先看第一个组的第一个页面，当然也是表空间的第一个页面，页号为 0 。这个页面的类型是 FSP_HDR ，它存储了表空间的一些整体属性以及第一个组内256个区的对应的 XDES Entry 结构，直接看这个类型的页面的示意图：
从图中可以看出，一个完整的 FSP_HDR 类型的页面大致由5个部分组成，各个部分的解释如下：
| 名称 | 中文名 | 占用空间大小 | 简单描述 |
|---|---|---|---|
| File Header | 文件头部 | 38 字节 | 页的一些通用信息 |
| File Space Header | 表空间头部 | 112 字节 | 表空间的一些整体属性信息 |
| XDES Entry | 区描述信息 | 10240 字节 | 存储本组256个区对应的属性信息 |
| Empty Space | 尚未使用空间 | 5986 字节 | 用于页结构的填充，没啥实际意义 |
| File Trailer | 文件尾部 | 8 字节 | 校验页是否完整 |
我们重点看看 File Space Header 和 XDES Entry 这两个部分。
- File Space Header部分
从名字就可以看出来，这个部分是用来存储表空间的一些整体属性的，如下图：
看看每个字段含义的简单描述：
| 名称 | 占用空间 大小 | 描述 |
|---|---|---|
| Space ID | 4 字节 | 表空间的ID |
| Not Used | 4 字节 | 这4个字节未被使用，可以忽略 |
| Size | 4 字节 | 当前表空间占有的页面数 |
| FREE Limit | 4 字节 | 尚未被初始化的最小页号，大于或等于这个页号的区对应的XDES Entry结构都没有被加入FREE链表 |
| Space Flags | 4 字节 | 表空间的一些占用存储空间比较小的属性 |
| FRAG_N_USED | 4 字节 | FREE_FRAG链表中已使用的页面数量 |
| List Base Node for FREE List | 16 字节 | FREE链表的基节点 |
| List Base Node for FREE_FRAG List | 16 字节 | FREE_FREG链表的基节点 |
| List Base Node for FULL_FRAG List | 16 字节 | FULL_FREG链表的基节点 |
| Next Unused Segment ID | 8 字节 | 当前表空间中下一个未使用的Segment ID |
| List Base Node for SEG_INODES_FULL List | 16 字节 | SEG_INODES_FULL链表的基节点 |
| List Base Node for SEG_INODES_FREE List | 16 字节 | SEG_INODES_FREE链表的基节点 |
部分字段说明：
- 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 部分。所以之后定位这几个链表就很简单了。 - FRAG_N_USED
这个字段表明在 FREE_FRAG 链表中已经使用的页面数量，方便之后在链表中查找空闲的页面。 - FREE Limit
我们知道表空间都对应着具体的磁盘文件，一开始我们创建表空间的时候对应的磁盘文件中都没有数据，所以我们需要对表空间完成一个初始化操作，包括为表空间中的区建立 XDES Entry 结构，为各个段建立INODE Entry 结构等。我们可以一开始就为表空间申请一个特别大的空间，但是实际上有绝大部分的区是空闲的，我们可以选择把所有的这些空闲区对应的 XDES Entry 结构加入FREE 链表，也可以选择只把一部分的空闲区加入 FREE 链表，等啥时候空闲链表中的 XDES Entry 结构对应
的区不够使了，再把之前没有加入 FREE 链表的空闲区对应的 XDES Entry 结构加入 FREE 链表，目的就是啥时候用到啥时候初始化，在Mysql中他们为表空间定义了 FREE Limit 这个字段，在该字段表示的页号之前的区都被初始化了，之后的区尚未被初始化。 - Next Unused Segment ID
表中每个索引都对应2个段，每个段都有一个唯一的ID，那当我们为某个表新创建一个索引的时候，就意味着要创建两个新的段。那怎么为这个新创建的段找一个唯一的ID呢？在Mysql中提出了这个名叫 NextUnused Segment ID 的字段，该字段表明当前表空间中最大的段ID的下一个ID，这样在创建新段的时候直接使用这个字段的值就可以了。 - Space Flags
表空间对于一些布尔类型的属性，或者只需要几个比特位表示的属性都放在了这个 Space Flags 中存储，虽然它只有4个字节，32个比特位大小，却存储了很多表空间的属性，具体如下：
| 标志名称 | 占用的空间（单位：bit） | 描述 |
|---|---|---|
| POST_ANTELOPE | 1 | 表示文件格式是否大于 ANTELOPE |
| ZIP_SSIZE | 4 | 表示压缩页面的大小 |
| ATOMIC_BLOBS | 1 | 表示是否自动把值非常长的字段放到BLOB页里 |
| PAGE_SSIZE | 4 | 页面大小 |
| DATA_DIR | 1 | 表示表空间是否是从默认的数据目录中获取的 |
| SHARED | 1 | 是否为共享表空间 |
| TEMPORARY | 1 | 是否为临时表空间 |
| ENCRYPTION | 1 | 表空间是否加密 |
| UNUSED | 18 | 没有使用到的比特位 |
注意：不同MySQL版本里 SPACE_FLAGS 代表的属性可能有些差异，我们这里列举的是5.7版本的。
- 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 结构。
XDES Entry部分
XDES Entry 也是在表空间的第一个页面中保存的。我们知道一个 XDES Entry 结构的大小是40字节，但是一个页面的大小有限，只能存放有限个 XDES Entry 结构，所以我们才把256个区划分成一组，在每组的第一个页面中存放256个 XDES Entry 结构。可以回看 FSP_HDR 类型页面的示意图， XDES Entry 0 就对应着 extent 0 ， XDESEntry 1 就对应着 extent 1 … 依此类推， XDES Entry255 就对应着 extent 255 。因为每个区对应的 XDES Entry 结构的地址是固定的，所以我们访问这些结构就很容易了。
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 部分之外，也就是除了少了记录表空间整体属性的部分之外，其余的部分是一样一样的。
BUF_BITMAP类型
对比前边介绍表空间的图，每个分组的第二个页面的类型都是 IBUF_BITMAP ，这种类型的页里边记录了一些有关Change Buffer 的相关信息。后续详细介绍。
INODE类型
从上面表空间的结构图可以看出第一个分组的第三个页面的类型是 INODE 。我们前边说过 InnoDB中每个索引定义了两个段，而且为某些特殊功能定义了些特殊的段。为了方便管理，他们又为每个段设计了一个INODE Entry 结构，这个结构中记录了关于这个段的相关属性。现在这个 INODE 类型的页就是为了存储 INODE Entry 结构而存在的。如下图：
从上图可以看出，一个 INODE 类型的页面是由这几部分构成的：
| 名称 | 中文名 | 占用空间大小 | 简单描述 |
|---|---|---|---|
| File Header | 文件头部 | 38 字节 | 页的一些通用信息 |
| List Node for INODE Page List | 通用链表节点 | 12 字节 | 存储上一个INODE页面和下一个INODE页面的指针 |
| INODE Entry | 段描述信息 | 16128 字节 | |
| Empty Space | 尚未使用空间 | 6 字节 | 用于页结构的填充，没啥实际意义 |
| File Trailer | 文件尾部 | 8 字节 | 校验页是否完整 |
除了 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 类型的页面，Mysql中将这些 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_BTR_SEG_LEAF | 10 字节 | B+树叶子段的头部信息，仅在B+树的根页定义 |
| PAGE_BTR_SEG_TOP | 10 字节 | B+树非叶子段的头部信息，仅在B+树的根页定义 |
其中的 PAGE_BTR_SEG_LEAF 和 PAGE_BTR_SEG_TOP 都占用10个字节，它们其实对应一个叫 Segment Header 的结
构，该结构图示如下：
各个部分的具体释义如下：
| 名称 | 占用字节数 | 描述 |
|---|---|---|
| Space ID of the INODE Entry | 4 | INODE Entry结构所在的表空间ID |
| Page Number of the INODE Entry | 4 | INODE Entry结构所在的页面页号 |
| Byte Offset of the INODE Ent | 2 | INODE Entry结构在该页面中的偏移量 |
这样子就很清晰了， PAGE_BTR_SEG_LEAF 记录着叶子节点段对应的 INODE Entry 结构的地址是哪个表空间的哪个页面的哪个偏移量， PAGE_BTR_SEG_TOP 记录着非叶子节点段对应的 INODE Entry 结构的地址是哪个表空间的哪个页面的哪个偏移量。这样子索引和其对应的段的关系就建立起来了。不过需要注意的一点是，因为一个索引只对应两个段，所以只需要在索引的根页面中记录这两个结构即可。
真实表空间对应的文件大小
我们到数据目录里看一个新建的表对应的 .ibd 文件，发现其实只占用了96K，才6个页面大小，其实是正常的。一开始表空间占用的空间自然是很小，因为表里边都没有数据嘛！不过这些 .ibd 文件是自扩展的文件，随着表中数据的增多，表空间对应的文件也逐渐增大。
系统表空间
了解完了独立表空间的基本结构，系统表空间的结构也就好理解多了，系统表空间的结构和独立表空间基本类似，只不过由于整个MySQL进程只有一个系统表空间，在系统表空间中会额外记录一些有关整个系统信息的页面，所以会比独立表空间多出一些记录这些信息的页面。因为这个系统表空间最牛逼，相当于是表空间之首，所以它的 表空间 ID （Space ID）是 0 。
系统表空间的整体结构
系统表空间与独立表空间的一个非常明显的不同之处就是在表空间开头有许多记录整个系统属性的页面，如图：
可以看到，系统表空间和独立表空间的前三个页面（页号分别为 0 、 1 、 2 ，类型分别是 FSP_HDR 、
IBUF_BITMAP 、 INODE ）的类型是一致的，只是页号为 3 ～ 7 的页面是系统表空间特有的，我们来看一下这些
多出来的页面的用途：
| 页号 | 页面类型 | 英文描述 | 描述 |
|---|---|---|---|
| 3 | SYS | Insert Buffer Header | 存储Insert Buffer的头部信息 |
| 4 | INDEX | Insert Buffer Root | 存储Insert Buffer的根页面 |
| 5 | TRX_SYS | Transction System | 事务系统的相关信息 |
| 6 | SYS | First Rollback Segment | 第一个回滚段的页面 |
| 7 | SYS | Data Dictionary Header | 数据字典头部信息 |
除了这几个记录系统属性的页面之外，系统表空间的 extent 1 和 extent 2 这两个区，也就是页号从 64 ~ 191这128个页面被称为 Doublewrite buffer ，也就是双写缓冲区。这些大部分知识都涉及到了事务和多版本控制的问题，这些问题我们在后续再进行分享。
InnoDB数据字典
我们平时使用 INSERT 语句向表中插入的那些记录称之为用户数据，MySQL只是作为一个软件来为我们来保管这些数据，提供方便的增删改查接口而已。但是每当我们向一个表中插入一条记录的时候，MySQL先要校验一下插入语句对应的表存不存在，插入的列和表中的列是否符合，如果语法没有问题的话，还需要知道该表的聚簇索引和所有二级索引对应的根页面是哪个表空间的哪个页面，然后把记录插入对应索引的 B+ 树中。所以说，MySQL除了保存着我们插入的用户数据之外，还需要保存许多额外的信息，比方说：
- 某个表属于哪个表空间，表里边有多少列
- 表对应的每一个列的类型是什么
- 该表有多少索引，每个索引对应哪几个字段，该索引对应的根页面在哪个表空间的哪个页面
- 该表有哪些外键，外键对应哪个表的哪些列
- 某个表空间对应文件系统上文件路径是什么等等
上述这些数据并不是我们使用 INSERT 语句插入的用户数据，实际上是为了更好的管理我们这些用户数据而不得已引入的一些额外数据，这些数据也称为元数据 。InnoDB存储引擎特意定义了一些列的内部系统表（internal system table）来记录这些这些 元数据 ：
| 表名 | 描述 |
|---|---|
| SYS_TABLES | 整个InnoDB存储引擎中所有的表的信息 |
| SYS_COLUMNS | 整个InnoDB存储引擎中所有的列的信息 |
| SYS_INDEXES | 整个InnoDB存储引擎中所有的索引的信息 |
| SYS_FIELDS | 整个InnoDB存储引擎中所有的索引对应的列的信息 |
| SYS_FOREIGN | 整个InnoDB存储引擎中所有的外键的信息 |
| SYS_FOREIGN_COLS | 整个InnoDB存储引擎中所有的外键对应列的信息 |
| SYS_TABLESPACES | 整个InnoDB存储引擎中所有的表空间信息 |
| SYS_DATAFILES | 整个InnoDB存储引擎中所有的表空间对应文件系统的文件路径信息 |
| SYS_VIRTUAL | 整个InnoDB存储引擎中所有的虚拟生成列的信息 |
这些系统表也被称为数据字典 ，它们都是以 B+ 树的形式保存在系统表空间的某些页面中，其中SYS_TABLES 、 SYS_COLUMNS 、 SYS_INDEXES 、 SYS_FIELDS 这四个表尤其重要，称之为基本系统表（basic system tables），我们先看看这4个表的结构：
SYS_TABLES表
mysql> show create table information_schema.INNODB_SYS_TABLES ;
注意不同版本的字段可能有所差异。
| 列名 | 描述 |
|---|---|
| TABLE_ID | InnoDB存储引擎中每个表都有一个唯一的ID |
| NAME | 表的名称 |
| FLAG | 有关表格式和存储特性的位级信息数据 |
| N_COLS | 该表拥有列的个数 |
| SPACE | 该表所属表空间的ID |
| FILE_FORMAT | 表空间文件的存储格式 |
| ROW_FORMAT | 行格式 |
| ZIP_PAGE_SIZE | 压缩页大小 |
| SPACE_TYPE | 表的类型，记录了一些文件格式、行格式、压缩等信息 |
SYS_COLUMNS表
mysql> show create table information_schema.INNODB_SYS_COLUMNS;
| 列名 | 描述 |
|---|---|
| TABLE_ID | 该列所属表对应的ID |
| NAME | 该列的名称 |
| POS | 该列在表中是第几列 |
| MTYPE | main data type，主数据类型，就是那堆INT、CHAR、V ARCHAR、FLOA T、DOUBLE之类的东东 |
| PRTYPE | precise type，精确数据类型，就是修饰主数据类型的那堆东东，比如是否允许NULL值，是否允许负数啥的 |
| LEN | 该列最多占用存储空间的字节数 |
SYS_INDEXES表
| 列名 | 描述 |
|---|---|
| INDEX_ID | 索引 ID |
| NAME | 该索引的名称 |
| TABLE_ID | 该索引所属表对应的ID |
| ID I | nnoDB存储引擎中每个索引都有一个唯一的ID |
| N_FIELDS | 该索引包含列的个数 |
| TYPE | 该索引的类型，比如聚簇索引、唯一索引、更改缓冲区的索引、全文索引、普通的二级索引等等各种类型 |
| SPACE | 该索引根页面所在的表空间ID |
| PAGE_NO | 该索引根页面所在的页面号 |
| MERGE_THRESHOLD | 如果页面中的记录被删除到某个比例，就把该页面和相邻页面合并，这个值就是这个比例 |
SYS_FIELDS表
| 列名 | 描述 |
|---|---|
| INDEX_ID | 该索引列所属的索引的ID |
| NAME | 该索引列的名称 |
| POS | 该索引列在某个索引中是第几列 |
Data Dictionary Header页面
只要有了上述4个基本系统表，也就意味着可以获取其他系统表以及用户定义的表的所有元数据。比方说我们想看看 SYS_TABLESPACES 这个系统表里存储了哪些表空间以及表空间对应的属性，那就可以：
- 到 SYS_TABLES 表中根据表名定位到具体的记录，就可以获取到 SYS_TABLESPACES 表的 TABLE_ID
- 使用这个 TABLE_ID 到 SYS_COLUMNS 表中就可以获取到属于该表的所有列的信息。
- 使用这个 TABLE_ID 还可以到 SYS_INDEXES 表中获取所有的索引的信息，索引的信息中包括对应的INDEX_ID ，还记录着该索引对应的 B+ 数根页面是哪个表空间的哪个页面。
- 使用 INDEX_ID 就可以到 SYS_FIELDS 表中获取所有索引列的信息。
也就是说这4个表是表中之表，那这4个表的元数据去哪里获取呢？没法搞了，只能把这4个表的元数据，就是它们有哪些列、哪些索引等信息硬编码到代码中，然后 在InnoDB 中又拿出一个固定的页面来记录这4个表的聚簇索引和二级索引对应的 B+树 位置，这个页面就是页号为 7 的页面，类型为 SYS ，记录了 Data DictionaryHeader ，也就是数据字典的头部信息。除了这4个表的5个索引的根页面信息外，这个页号为 7 的页面还记录了整个InnoDB存储引擎的一些全局属性，这个页面的示意图如下：
可以看到这个页面由下边几个部分组成：
| 名称 | 中文名 | 占用空间大小 | 简单描述 |
|---|---|---|---|
| File Header | 文件头部 | 38 字节 | 页的一些通用信息 |
| Data Dictionary Header | 数据字典头部信息 | 56 字节 | 记录一些基本系统表的根页面位置以及InnoDB存储引擎的一些全局信息 |
| Segment Header | 段头部信息 10 字节 记录本页面所在段对应的INODE Entry位置信息 | ||
| Empty Space | 尚未使用空间 | 16272 字节 | 用于页结构的填充，没啥实际意义 |
| File Trailer | 文件尾部 | 8 字节 | 校验页是否完整 |
可以看到这个页面里有 Segment Header 部分，意味着Innodb中把这些有关数据字典的信息当成一个段来分配存储空间，我们就暂且称之为数据字典段吧。由于目前我们需要记录的数据字典信息非常少（可以看到 Data Dictionary Header 部分仅占用了56字节），所以该段只有一个碎片页，也就是页号为 7 的这个页。
接下来我们需要看一下 Data Dictionary Header 部分的各个字段：
- Max Row ID ：我们说过如果我们不显式的为表定义主键，而且表中也没有 UNIQUE 索引，那么 InnoDB 存储引擎会默认为我们生成一个名为 row_id 的列作为主键。因为它是主键，所以每条记录的 row_id 列的值不能重复。原则上只要一个表中的 row_id 列不重复就可以了，也就是说表a和表b拥有一样的 row_id 列也没啥关系，不过InnoDB中只提供了这个 Max Row ID 字段，不论哪个拥有 row_id 列的表插入一条记录时，该记录的 row_id 列的值就是 Max Row ID 对应的值，然后再把 Max Row ID 对应的值加1，也就是说这个 Max Row ID 是全局共享的。
- Max Table ID ：InnoDB存储引擎中的所有的表都对应一个唯一的ID，每次新建一个表时，就会把本字段的值作为该表的ID，然后自增本字段的值。
- Max Index ID ：InnoDB存储引擎中的所有的索引都对应一个唯一的ID，每次新建一个索引时，就会把本字段的值作为该索引的ID，然后自增本字段的值。
- Max Space ID ：InnoDB存储引擎中的所有的表空间都对应一个唯一的ID，每次新建一个表空间时，就会把本字段的值作为该表空间的ID，然后自增本字段的值。
- Mix ID Low(Unused) ：这个字段没啥用，跳过。
- Root of SYS_TABLES clust index ：本字段代表 SYS_TABLES 表聚簇索引的根页面的页号。
- Root of SYS_TABLE_IDS sec index ：本字段代表 SYS_TABLES 表为 ID 列建立的二级索引的根页面的页
号。 - Root of SYS_COLUMNS clust index ：本字段代表 SYS_COLUMNS 表聚簇索引的根页面的页号。
- Root of SYS_INDEXES clust index 本字段代表 SYS_INDEXES 表聚簇索引的根页面的页号。
- Root of SYS_FIELDS clust index ：本字段代表 SYS_FIELDS 表聚簇索引的根页面的页号。
- Unused ：这4个字节没用，跳过。
information_schema系统数据库
需要注意一点的是，用户是不能直接访问 InnoDB 的这些内部系统表的，除非你直接去解析系统表空间对应文件
系统上的文件。但是InnoDB中考虑到查看这些表的内容可能有助于大家分析问题，所以在系统数据库information_schema 中提供了一些以 innodb_sys 开头的表。
mysql> use information_schema;
Database changed
mysql> show tables like "INNODB_SYS%";
+--------------------------------------------+
| Tables_in_information_schema (INNODB_SYS%) |
+--------------------------------------------+
| INNODB_SYS_DATAFILES |
| INNODB_SYS_VIRTUAL |
| INNODB_SYS_INDEXES |
| INNODB_SYS_TABLES |
| INNODB_SYS_FIELDS |
| INNODB_SYS_TABLESPACES |
| INNODB_SYS_FOREIGN_COLS |
| INNODB_SYS_COLUMNS |
| INNODB_SYS_FOREIGN |
| INNODB_SYS_TABLESTATS |
+--------------------------------------------+
10 rows in set (0.00 sec)
在 information_schema 数据库中的这些以 INNODB_SYS 开头的表并不是真正的内部系统表（内部系统表就是我们上面说的以 SYS 开头的那些表），而是在存储引擎启动时读取这些以 SYS 开头的系统表，然后填充到这些以INNODB_SYS 开头的表中。以 INNODB_SYS 开头的表和以 SYS 开头的表中的字段并不完全一样，但可供参考。
更多关于mysql的知识分享，请前往博客主页。编写过程中，难免出现差错，敬请指出
![[WMCTF2020]Make PHP Great Again require_once 特性](https://img-blog.csdnimg.cn/direct/2f0b88c35d774a18a27f5cb65dfa64b7.png)
