前言：
这部分的内容有点……难理解，个人感觉文字性描述太强，所以记一些基础的内容吧
独立表空间结构
对数据页不太理解的可以回顾一下上篇内容
区
前言
为提出一个 区 （ extent ）的概念呢？
如果我们表中数据量很少的话，比如说你的表中只有几十条、几百条数据的话，的确用不到区的概念，
因为简单的几个页就能把对应的数据存储起来，但是你架不住表里的记录越来越多呀。
理论上说：B+ 树的每一层中的页都会形成一个双向链表，不引入 区 的概念只使用 页 的概念对存储引擎的运行并没啥影响
但：
我们每向表中插入一条记录，本质上就是向该表的聚簇索引以及所有二级索引代表的 B+ 树的节点中插入数
据。而 B+ 树的每一层中的页都会形成一个双向链表，如果是以 页 为单位来分配存储空间的话，双向链表相
邻的两个页之间的物理位置可能离得非常远。 B+ 树索引的范围查询只需要定位到最左边的记录和最右边的记录，然后沿着双向链表一直扫描就可以了，而如果链表中相邻的两个页物理位置离得非常远，就是所谓的 随机I/O 。磁盘的速度和内存的速度差了好几个数量级， 随机I/O 是非常慢的，所以我们应该尽量让链表中相邻的页的物理位置也相邻，这样进行范围查询的时候才可以使用所谓的 顺序I/O 。
所以，为了减少随机I/O
在表中数据量大的时候，为某个索引分配空间的时候就不再按照页为单位分配了，而是按照 区 为单位分配，甚至在表中的数据十分非常特别多的时候，可以一次性分配多个连续的区。虽然可能造成一点点空间的浪费（数据不足填充满整个区），但是从性能角度看，可以消除很多的随机 I/O。
概述
当表空间中的页数据非常多的时候，为了更好的管理这些页面，设计者提出了区 （英文名： extent ）的概念。对于16KB的页来说，连续的64个页就是一个区，也就是说一个区默认占用1MB空间大小。不论是系统
表空间还是独立表空间，都可以看成是由若干个区组成的，每256个区被划分成一组。画个图表示就是这样：
其中 extent 0 ~ extent 255 这256个区算是第一个组，
extent 256 ~ extent 511 这256个区算是第二个组， extent 512 ~ extent 767 这256个区算是第三个组
从图中可以得知：
1、第一个组最开始的3个页面的类型是固定的，也就是说 extent 0 这个区最开始的3个页面的类型是固定的
FSP_HDR 类型：这个类型的页面是用来登记整个表空间的一些**整体属性**以及本组所有的区 ，
也就是extent 0 ~ extent 255 这256个区的属性
IBUF_BITMAP 类型：这个类型的页面是存储本组所有的区的所有页面关于 INSERT BUFFER 的信息。
2、其余各组最开始的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 类型的页面还会额外存储一些表空间的属性。
总结
总结：表空间被划分为许多连续的区 ，每个区默认由64个页组成，每256个区划分为一组，每个组的最开始的几个页面类型是固定的就好了。
段
概述
为什么还要有段的概念呢？
前面提到的范围查询，其实是对 B+ 树叶子节点中的记录进行顺序扫描，而如果不区分叶子节点和非叶子节点，统统把节点代表的页面放到申请到的区中的话，进行范围扫描的效果就大打折扣了。为了对 B+ 树的叶子节点和非叶子节点进行了区别对待，也就是说叶子节点有自己独有的 区 ，非叶子节点也有自己独有的 区 。存放叶子节点的区的集合就算是一个 段 （ segment ），存放非叶子节点的区的集合也算是一个 段 。也就是说一个索引会生成2个段，一个叶子节点段，一个非叶子节点段。
简单点说就是：在上面的图中，如果一个区里既有叶子节点的页，又有非叶子节点的页，那么进行范围查询，不也和随机io一样吗，不够纯粹。
分配存储空间的策略
默认情况下一个使用 InnoDB 存储引擎的表只有一个聚簇索引，一个索引会生成2个段，而段是以区为单位申请存储空间的，一个区默认占用1M存储空间。
但默认情况下一个只存了几条记录的小表也需要2M的存储空间吗？以后每次添加一个索引都要多申请2M的存储空间么？
这个问题的症结在于目前说的区都是非常纯粹的，也就是一个区被整个分配给某一个段，或者说区中的所有页面都是为了存储同一个段的数据而存在的，即使段的数据填不满区中所有的页面，那余下的页面也不能挪作他用。
现在为了考虑以完整的区为单位分配给某个段对于数据量较小的表太浪费存储空间的这种情况，有一个碎片（fragment）区的概念，也就是在一个碎片区中，并不是所有的页都是为了存储同一个段的数据而存在的，而是碎片区中的页可以用于不同的目的，比如有些页用于段A，有些页用于段B，有些页甚至哪个段都不属于。
碎片区直属于表空间，并不属于任何一个段。所以此后为某个段分配存储空间的策略是这样的：
在刚开始向表中插入数据的时候，段是从某个碎片区以单个页面为单位来分配存储空间的。
当某个段已经占用了32个碎片区页面之后，就会以完整的区为单位来分配存储空间。
所以现在**段不能仅定义为是某些区的集合，更精确的应该是某些零散的页面以及一些完整的区的集合**。
除了索引的叶子节点段和非叶子节点段之外， InnoDB 中还有为存储一些特殊的数据而定义的段，比如回滚段。
总结
个人理解就是：比如我们日常写了个demo，里面的表几张；数据估计就几百条，此时数据的实际占用内存估计不到2M，那么InnoDB在分配内存空间的时候：
比如表A，它会生成两个段，刚开始数据不多，所以不会分配2M空间。而这些数据就会放进碎片区中，用碎片区的单位页作为存储空间，此时两个段A中只包含碎片区。
如果A表的数据都已经占满了32个碎片区了，那才申请一个2M的属于A表的两个完整段，多出来的数据依旧先放在碎片区，那么此时段A中就既有属于段A的一个完整的区，以及部分碎片区的零散页。
那么怎么知道这个区属于哪个段呢?
Segment ID
区的分类
区大体上可以分为4种类型：
- 空闲的区：现在还没有用到这个区中的任何页面。
- 有剩余空间的碎片区：表示碎片区中还有可用的页面。
- 没有剩余空间的碎片区：表示碎片区中的所有页面都被使用，没有空闲页面。
- 附属于某个段的区。每一个索引都可以分为叶子节点段和非叶子节点段，除此之外InnoDB还会另外定义一些
特殊作用的段，在这些段中的数据量很大时将使用区来作为基本的分配单位。
这4种类型的区也可以被称为区的4种状态（ State ）：
| 状态名 | 含义 |
|---|---|
| FREE | 空闲的区 |
| FREE_FRAG | 有剩余空间的碎片区 |
| FULL_FRAG | 没有剩余空间的碎片区 |
| FSEG | 附属于某个段的区 |
ps：处于 FREE 、 FREE_FRAG 以及 FULL_FRAG 这三种状态的区都是独立的，算是直属于表空间；而处于 FSEG 状态的区是附属于某个段的。
为了方便管理这些区，每一个区都对应着一个 XDES Entry 结构（全称就是Extent Descriptor Entry），这个结构记录了对应的区的一些属性。
Segment ID （8字节）
每一个段都有一个唯一的编号，用ID表示，此处的 Segment ID 字段表示就是该区所在的段。当然前提是该
区已经被分配给某个段了，不然的话该字段的值没啥意义。
所以，一个区怎么知道是哪个段的呢？就是看这个编号。
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个页面。这两个比特位的第一个位表示对应的页是否是空闲的，第二个
比特位还没有用。
List Node （12字节）
这个部分可以将若干个 XDES Entry 结构串联成一个链表
如果我们想定位表空间内的某一个位置的话，只需指定页号以及该位置在指定页号中的页内偏移量即可。所以：
Pre Node Page Number 和 Pre Node Offset 的组合就是指向前一个 XDES Entry 的指针
Next Node Page Number 和 Next Node Offset 的组合就是指向后一个 XDES Entry 的指针。
XDES Entry链表
向表中插入数据本质上就是向表中各个索引的叶子节点段、非叶子节点段插入数据，现在捋一捋向某个段中插入数据的过程：
-
当段中数据较少的时候，首先会查看表空间中是否有状态为有剩余空间的碎片区（FREE_FRAG） 的区，如果找到了，那么从该区中取一些零碎的页把数据插进去；否则到表空间下申请一个状态为 空闲的区（FREE） 的区，把该区的状态变为 FREE_FRAG ，然后从该新申请的区中取一些零碎的页把数据插进去。之后不同的段使用零碎页的时候都会从该区中取，直到该区中没有空闲空间，然后该区的状态就变成了**没有剩余空间的碎片区（FULL_FRAG） **。
-
当段中数据已经占满了32个零散的页后，就直接申请完整的区来插入数据了。
现在的问题是你怎么知道表空间里的哪些区是 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 ，然后从这个节点对应的区中获取零碎的页就好了。
但是，虽然现在知道什么区是什么状态了，但怎么知道哪个区属于哪个段呢？
把状态为 FSEG 的区对应的 XDES Entry 结构都加入到一个链表？但不同的段哪能共用一个区呢？把索引a的叶子节点段和索引b的叶子节点段都存储到一个区中是不可行的。
显然我们想要每个段都有它独立的链表，如果根据段号（也就是 Segment ID ）来建立链表，有多少个段就建多少个链表？好像也有点问题，因为一个段中可以有好多个区，有的区是完全空闲的，有的区还有一些页面可以用，有的区已经没有空闲页面可以用了，所以我们有必要继续细分。
设计者为每个段中的区对应的 XDES Entry 结构建立了三个链表：
FREE 链表：同一个段中，所有页面都是空闲的区对应的 XDES Entry 结构会被加入到这个链表。注意和
直属于表空间的 FREE 链表区别开了，此处的 FREE 链表是附属于某个段的。
NOT_FULL 链表：同一个段中，仍有空闲空间的区对应的 XDES Entry 结构会被加入到这个链表。
FULL 链表：同一个段中，已经没有空闲空间的区对应的 XDES Entry 结构会被加入到这个链表
eg：
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 链表中。
个人理解
表空间会维护三个链表，这三个链表是碎片区的，碎片区的也怎么知道是属于哪个段的？Segment ID
段中维护的链表是属于段的，是在碎片区里占满了32个碎片区后才分配的，完全属于某个段的。
链表基节点
现在知道什么区是什么状态了，知道哪个区属于哪个段了，也知道会维护链表了，那么我怎么知道链表维护在哪里呢？
设计者对此设计了一个叫 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 结构放置在表空间中固定的位置，这样想找定位某个链表就变得很容易。看File Space Header部分
小结
综上所述，表空间是由若干个区组成的，每个区都对应一个 XDES Entry 的结构，直属于表空间的区对应的 XDES
Entry 结构可以分成 FREE 、 FREE_FRAG 和 FULL_FRAG 这3个链表；每个段可以附属若干个区，每个段中的区对
应的 XDES Entry 结构可以分成 FREE 、 NOT_FULL 和 FULL 这3个链表。每个链表都对应一个 List Base Node 的
结构，这个结构里记录了链表的头、尾节点的位置以及该链表中包含的节点数。
段的结构
前言
段其实不对应表空间中某一个连续的物理区域，而是一个逻辑上的概念，由若干个零散的页面以及一些完整的区组成。像每个区都有对应的 XDES Entry 来记录这个区中的属性一样，每个段也定义了一个 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 。
段里可能不止一种类型一条链表，所以可能会有多条多个类型的List Base Node组成的链表，这就是这个三个链表的组成
Magic Number ：
这个值是用来标记这个 INODE Entry 是否已经被初始化了（初始化的意思就是把各个字段的值都填进去
了）。如果这个数字是值的 97937874 ，表明该 INODE Entry 已经初始化，否则没有被初始化。（不用纠结
这个值有啥特殊含义，人家规定的）。
Fragment Array Entry
段是一些零散页面和一些完整的区的集合，每个 Fragment Array Entry 结构都对应着一个零散的页面，这个结构一共4个字节，表示一个零散页面的页号。
所以为啥前面说占满32个碎片区后才分配完整的区，正因如此。
各类型页面详细情况
大概清楚了表空间、段、区、XDES Entry、INODE Entry、各种以 XDES Enty 为节点的链表的基本概念了，可是总有一种飞在天上不踏实的感觉，每个区对应的 XDES Entry 结构到底存储在表空间的什么地方？直属于表空间的 FREE 、 FREE_FRAG 、 FULL_FRAG 链表的基节点到底存储在表空间的什么地方？每个段对应的 INODE Entry 结构到底存在表空间的什么地方？
总结就是他们都在表空间的哪里？
FSP_HDR 类型
第一个组的第一个页面，当然也是表空间的第一个页面，页号为 0 。这个页面的类型是 FSP_HDR ，它存储了表空间的一些整体属性以及第一个组内256个区的对应的 XDES Entry 结构。
各部分释义：
File Space Header部分
存储表空间的一些整体属性
各部分释义：
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 链表，中心思想就是啥时候用到啥时候初始化，
设计 InnoDB 的大叔采用的就是后者，他们为表空间定义了 FREE Limit 这个字段，在该字段表示的页号之前的区都被初始化了，之后的区尚未被初始化。
Next Unused Segment ID
表中每个索引都对应2个段，每个段都有一个唯一的ID，那当我们为某个表新创建一个索引的时候，就意味
着要创建两个新的段。那怎么为这个新创建的段找一个唯一的ID呢？去遍历现在表空间中所有的段么？所以设计 InnoDB 的大叔们提出了这个名叫 NextUnused Segment ID 的字段，该字段表明当前表空间中最大的段ID的下一个ID，这样在创建新段的时候赋予新段一个唯一的ID值就容易了，直接使用这个字段的值就好了。
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 结
构。
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 类型
前面说的 FSP_HDR 类型，整个表空间里只有一个这个类型的页面。除去第一个分组以外，之后的每个分组的第一个页面只需要记录本组内所有的区对应的 XDES Entry 结构即可，不需要再记录表空间的属性了，为了和 FSP_HDR 类型做区别，我们把之后每个分组的第一个页面的类型定义为 XDES ，它的结构和 FSP_HDR 类型是非常相似的：
与 FSP_HDR 类型的页面对比，除了少了 File Space Header 部分之外，也就是除了少了记录表空间整体属性的部分之外，其余的部分是一样一样的。
IBUF_BITMAP 类型
略
INODE 类型
InnoDB 为每个索引定义了两个段，而且为某些特殊功能定义了些特殊的段。为了方便管理，他们又为每个段设计了一个INODE Entry 结构（前言部分），这个结构中记录了关于这个段的相关属性。而这个 INODE 类型的页就是为了存储 INODE Entry 结构而存在的。
各部分释义：
重点看一下 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_BTR_SEG_LEAF 和 PAGE_BTR_SEG_TOP 都占用10个字节，它们其实对应一个叫 Segment Header 的结
构，该结构图示如下：
各部分释义：
PAGE_BTR_SEG_LEAF 记录着叶子节点段对应的 INODE Entry 结构的地址是哪个表空间的哪个页面的哪个偏移量， PAGE_BTR_SEG_TOP 记录着非叶子节点段对应的 INODE Entry 结构的地址是哪个表空间的哪个页面的哪个偏移量。这样子索引和其对应的段的关系就建立起来了。不过需要注意的一点是，因为一个索引只对应两个段，所以只需要在索引的根页面中记录这两个结构即可。
系统表空间
以上说的都是独立表空间
系统表空间的结构和独立表空间基本类似，只不过由于整个MySQL进程只有一个系统表空间，在系统表空间中会额外记录一些有关整个系统信息的页面，所以会比独立表空间多出一些记录这些信息的页面。因为这个系统表空间最牛逼，相当于是表空间之首，所以它的 表空间 ID （Space ID）是 0 。
结构
