表空间是一个抽象的概念，系统表空间对应着文件系统中一个或多个实际文件；
独立表空间对应着文件系统中一个名为 表名.ibd 的实际文件。
可以把表空间想象成被切分为许多个页的池子，当我们想为某个表插入一条记录的时候，就从池子中捞出一个对应的页来把数据写进去。
我们知道 InnoDB 支持许多种类型的表空间，本章重点关注独立表空间和系统表空间的结构。
它们的结构比较相似，但是由于系统表空间中额外包含了一些关于整个系统的信息。

独立表空间结构

区的概念

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

在表中数据量大的时候，为某个索引分配空间的时候就不再以页为单位分配了，而是以区为单位分配，
甚至在表中数据特别多的时候，可以一次性分配多个连续的区。
这样虽然可能会造成一点空间的浪费（数据不足以填充满整个区），但是从性能角度看，可以消除很多随机 I/O，功大于过。
对于 16KB 的页来说，连续的 64 个页就是一个区，也就是说一个区默认占用 1MB 空间大小。
不论是系统表空间还是独立表空间，都可以看成是由若干个区组成的，
连续的 256 个区被划分成一组。如图所示：

组中的前几个页面的类型是类似的，如图所示：

页面的类型
InnoDB 数据页结构
从上图中我们能得到如下信息：
第一个组的前 3 个页面的类型是固定的，也就是说 extent0 区的前 3 个页面的类型是固定的，分别是：

• fil_page_type_fsp_hdr：这个类型的页面存储表空间的一些整体属性以及本组 256 个区的属性，整个表空间只有一个 fsp_hdr 类型的页面。
• fil_page_ibuf_bitmap：这个类型的页面存储本组所有的区的所有页面关于 Insert Buffer 的信息。后面会详细介绍
• fil_page_inode：这个类型的页面存储了许多称为 inode 的数据结构。后面会详细介绍

其余各组的前 2 个页面的类型是固定的，分别是：

• fil_page_type_xdes：全称是 extent descriptor，用来存储本组 256 个区的属性，上边介绍的 fsp_hdr类型的页面和 xdes 类型的页面的作用类似，只不过 fsp_hdr 类型的页面还会额外存储一些表空间的属性。
• fil_page_ibuf_bitmap：上边已经介绍过，和上面同。

只要大致记得：表空间被划分为许多连续的区，每个区默认由 64 个页组成，每 256 个区划分为一组，每个组的前几个页面类型是固定的。

段的概念

范围查询是对 B+树叶子节点中的记录进行顺序扫描，如果不区分叶子节点和非叶子节点，统统把节点代表的页面放入申请到的区中的话，链表中相邻的两个页物理位置离得非常远，就是所谓的随机 I/O，进行范围扫描的效果就大打折扣了。

所以设计 InnoDB 的人对 B+树的叶子节点和非叶子节点进行了区别对待，
叶子节点有自己独有的区，非叶子节点也有自己独有的区。
存放叶子节点的区的集合就算是一个段 (segment)，存放非叶子节点的区的集合也算是一个段。
也就是说：一个索引会生成 2 个段，一个叶子节点段，一个非叶子节点段。
段是以区为单位申请存储空间的。

一个使用 InnoDB 存储引擎的表默认有一个聚簇索引，一个索引会生成 2 个段，
而段是以区为单位申请存储空间的，一个区默认占用 1M 存储空间，
所以默认情况下，一个只存了几条记录的小表也需要 2M 的存储空间吗？
以后每次添加一个索引都要多申请 2M 的存储空间么？
这对于存储记录比较少的表来说是很大的浪费。

但实际并不是这样的。
这个问题的症结在于到现在为止我们介绍的区都是非常纯粹的，
也就是一个区被整个分配给某一个段，或者说：区中的所有页面都是为了存储同一个段的数据而存在的，即使段的数据填不满区中所有的页面，那余下的页面也不能挪作他用。
考虑 以完整的区为单位分配给某个段，对于数据量较小的表太浪费存储空间的这种情况，
设计 InnoDB 的人提出了一个碎片 (fragment) 区的概念，在一个碎片区中，并不是所有的页都是为了存储同一个段的数据而存在的，而是碎片区中的页可以用于不同的段。
比如一个碎片区中的有些页用于段 A，有些页用于段 B，甚至有些页哪个段都不属于。
碎片区直属于表空间，并不属于任何一个段。

所以为某个段分配存储空间的策略是这样的：

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

所以段不能仅定义为是某些区的集合，更精确的应该是，段是某些零散的页面以及一些完整的区的集合。

除了索引的叶子节点段和非叶子节点段之外，InnoDB 中还有为存储一些特殊的数据而定义的段，比如：回滚段。

区的分类 & XDES Entry 结构

通过上边的介绍，已经知道了表空间的是由若干个区组成的，这些区大体上可以分为 4 种类型，这 4 种类型的区也可以被称为区的 4 种状态 (State)：

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

处于 free、free_frag 以及 full_frag 这三种状态的区都是独立的，算是直属于表空间；
而处于 fseg 状态的区是附属于某个段的。

小贴士：
如果把表空间比作是一个集团军，段就相当于师，区就相当于团。 一般的团都是隶属于某个师的，就像是处于 fseg 状态的区全都隶属于某个段， 而处于 free 、free_frag以及 full_frag 这三种状态的区却直接隶属于表空间，就像独立团直接听命于军部一样。

XDES Entry 的结构

为了方便管理这些区，设计 InnoDB 的人设计了一个称为 XDES Entry 的结构
全称是：Extent Descriptor Entry，每一个区都对应一个 XDES Entry 结构，
这个 XDES Entry 结构存储了对应的区的一些属性。

XDES Entry 的结构如图所示：

从图中可以看出，XDES Entry 是一个占用 40 个字节大小的结构，它大致分为 4 个部分，
各个部分的介绍如下：

• Segment ID（8字节）：每一个段都有一个唯一的编号，此处的 Segment ID 的值就是该区所在的段的编号。
• List Node（12字节）：该结构可以将若干个 XDES Entry 结构串联成一个链表，后面会介绍 XDES Entry 结构组成的链表问题，如果我们想定位表空间内的某一个位置的话，只需指定页号以及该位置在指定页号中的页内偏移量即可，所以：
  • Pre Node Page Number 和 Pre Node Offset 的组合就是指向前一个 XDES Entry 的指针
  • Next Node Page Number 和 Next Node Offset 的组合就是指向后一个 XDES Entry 的指针
• State（4字节）：这个字段表明区的状态。可选的状态值就是前边说过的那 4 个，分别是：free、free_frag、full_frag、fseg。
• Page State Bitmap（16字节）：这个部分共占用 128 个比特位。

一个区默认有 64 个页，这 128 个比特位被划分为 64 个部分，
每个部分占 2 个比特位，每个部分对应区中的一个页面。
比如：Page State Bitmap 部分的第 1 和第 2 个比特位对应着区中的第 1 个页面，
第 3 和第 4 个比特位对应着区中的第 2 个页面，依此类推。
这两个比特位的第一个位表示：对应的页是否是空闲的，第二个比特位还没有被设计者用到。

形成 XDES Entry 链表

设计 Innodb 的人把事情搞这么麻烦的初心仅仅是想提高向表中插入数据的效率，又不至于数据量少的表浪费空间。
我们已经知道了：向一个表中插入数据本质上就是向该表的所有索引（包括聚簇、二级）的叶子节点段、非叶子节点段插入数据，也知道了不同的区有不同的状态
下面捋一捋向某个段中插入数据的过程：

1. 当段中数据较少的时候，首先会查看表空间中是否有状态为 free_frag 的区，也就是找还有空闲空间的碎片区，
   • 如果找到了有空闲空间的碎片区，那么从该碎片区中取一些零碎的页把数据插进去
   • 如果没有找到有空闲空间的碎片区，则到表空间下申请一个状态为 free 的区，也就是空闲的区，把该区的状态变为 free_frag，然后从该新申请的碎片区中取一些零碎的页把数据插进去。

之后不同的段使用零碎页的时候都会从该区中取，直到该区中没有空闲空间，然后该区的状态就
变成了 full_frag。

现在的问题是：你怎么知道表空间里的哪些区的状态是 free，哪些区的状态是 free_frag？
这时候就是 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 字段值，然后从这个节点对应的区中获取零碎的页。

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

现在的问题是：你怎么知道哪个区属于哪个段的呢？
设计 InnoDB 的人为每个段中的区对应的 XDES Entry 结构建立了三个链表：

• free 链表：同一个段中，所有页面都是空闲的区对应的 XDES Entry 结构会被加到该链表。

这个和直属于表空间的 free 链表不同，此处的 free 链表里的区是附属于某个段的，其状态为 fseg。

• not_full 链表：同一个段中，仍有空闲空间的区对应的 XDES Entry 结构会被加到该链表。
• full 链表：同一个段中，已经没有空闲空间的区对应的 XDES Entry 结构会被加到该链表。

每一个索引都对应两个段，每个段都会维护上述的3个链表。
所以当段中数据已经占满 32 个零散的页后，要申请完整的区来插入数据的话，
会先获取 not_full 链表的头节点，直接把数据插入这个头节点对应的区中，
如果该区的空间已经被用完了，就把该节点移到 full 链表中。

链表基节点
我们怎么找到这些链表呢?
或者说：要怎么找到某个链表的头节点或者尾节点在表空间中的位置呢？
设计 InnoDB 的人设计了一个叫 List Base Node 的结构，即链表的基节点。
这个 List Base Node 结构中包含了链表的头节点和尾节点的指针以及这个链表中包含了多少节点的信息，这个 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 的结构，
直属于表空间的区对应的 XDES Entry 结构可以分成 free、free_frag、full_frag 这 3 个链表。
每个段可以附属若干个区，每个段中的区对应的 XDES Entry 结构可以分成 free、not_full、full这 3 个链表。
每个链表都对应一个 List Base Node 结构，这个结构里记录了链表的头、尾节点的位置以及该链表中包含的节点数。
正是因为这些链表的存在，管理这些区才变得简单。

INODE Entry 结构

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

INODE Entry 结构如图所示：

INODE Entry 结构的各个部分释义如下：
Segment ID：这个字段是指这个 INODE Entry 结构对应的段的编号 (ID)。
not_full_n_used：这个字段是指在 not_full 链表各 XDES Entry 节点对应的区已经使用了多少个页面。
一个区中有 64 个页面，如果不标记已经使用了多少页面的话，每次向段中插入数据时都要从第一
个页面进行遍历寻找空闲页面，有了这个字段之后就可以快速定位空闲页面。
段的 free 链表、not_full 链表、full 链表的基节点：这样我们想查找某个段的某个区的头节点时，就可以直接到这个部分找到对应链表的 List Base Node。
Magic Number：这个值是用来标记这个 INODE Entry 结构是否已经被初始化。
初始化的意思是：把各个字段的值填进去，如果这 Magic Number 的值为 97937874，表明该 INODE Entry 结构已经被初始化，否则表明没有被初始化。
Fragment Array Entry：段是一些零散页面和一些完整的区的集合，每个 Fragment Array Entry 结构都对应着一个零散的页面，一个 Fragment Array Entry 结构占 4 个字节，表示一个零散页面的页号。

不同类型的页面

InnoDB 数据页结构
每个区对应的 XDES Entry 结构存储在表空间的什么地方？
直属于表空间的 free、free_frag、full_frag 链表的基节点存储在表空间的什么地方？
每个段对应的 INODE Entry 结构存在表空间的什么地方？
将 256 个连续的区划分为一个组，想解决上面的疑问还得从每个组开头的一些类型相同的页面说起，

组中的前几个页面的类型是类似的，如图所示：

fil_page_type_fsp_hdr 类型

第一个组的第一个页面，即页号为 0 的页面。
这个页面的类型是 fsp_hdr，它存储了表空间的一些整体属性以及第一个组内的 256个区对应的 XDES Entry 结构。
fsp_hdr 类型的页面的结构如图所示：

从图中可以看出，fsp_hdr 类型的页面大致由 5 个部分组成，各个部分的具体释义如下表所示：

下面介绍一下 File Space Header 和 XDES Entry 这两个部分。

File Space Header 部分
这个部分用来存储表空间的一些整体属性信息，
File Space Header 的结构如图所示：

File Space Header 的结构中各个属性的描述如表所示：

List Base Node for free List、
List Base Node for free_frag List、
List Base Node for full_frag List：直属于表空间的链表的基节点，
这三个链表的基节点在表空间的位置是固定的，就是在表空间的第一个页面，
也就是 fsp_hdr 类型的页面的 File Space Header 部分。
frag_n_used：这个字段表明在 free_frag 链表中每个区已使用的页面数量，方便之后查找空闲的页面。
FREE Limit：表空间对应着具体的磁盘文件，
一开始创建表空间时，对应的磁盘文件中没有数据，需要对表空间进行一个初始化操作，
初始化操作包括：为表空间中的区建立 XDES Entry 结构，为各个段建立 INODE Entry 结构，建立各种链表等各种操作。
设计 Innodb 的人设计的是：只把一部分的空闲区加入 free 链表，
等什么时候 free 链表中的 XDES Entry 结构对应的区不够使用了，再把没有加入 free 链表的空闲区对应的XDES Entry 结构加入 free 链表，
中心思想就是：什么时候用到什么时候再初始化。
设计 InnoDB 的人为表空间定义了 FREE Limit 这个字段，在该字段表示的页号之前的区都已经被初始化了，之后的区尚未被初始化。
Next Unused Segment ID：每个索引都对应 2 个段，每个段都有一个唯一的 ID，为某个表新创建一个索引的时候，就意味着要创建两个新的段。
那如果为这个新创建的段找一个唯一的 ID 呢？
Next Unused Segment ID 字段就表明：当前表空间中最大的段 ID 的下一个 ID，这样在创建新段的时候，直接将这个值作为新段的 ID 值。
Space Flags：表空间对于一些布尔类型的属性，或者只需要几个比特位就可以记录的属性都放在了这个Space Flags 中存储，
虽然它只有 4 个字节，32 个比特位大小，却存储了很多表空间的属性，详细情况如下表所示：

小贴士：
不同 MySQL 版本里 Space_Flags 代表的属性可能有差异， 这里列举的是 5.7.21 版本的。

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_full 链表，该链表中的 INODE 类型的页面仍有空闲空间用于存放 INODE Entry 结构。

XDES Entry 部分
XDES Entry 就是在表空间的第一个页面中存储的。
我们知道一个 XDES Entry 结构占 40 个字节，但是一个页面的大小有限，
只能存放有限个 XDES Entry 结构，所以我们才把 256 个区划分成一组，
在每组的第一个页面中存放 256个XDES Entry 结构。
因为每个区对应的 XDES Entry 结构的地址是固定的，所以访问这些结构是十分容易的。

fil_page_type_xdes 类型

每一个 XDES Entry 结构对应表空间的一个区。
表空间的第一个页面除了记录本组中的所有区对应的 XDES Entry 结构外，
还记录着表空间的一些整体属性。
除去第一个分组以外，之后的每个分组的第一个页面只需要记录本组内所有的区对应的 XDES Entry 结构即可，不需要再记录表空间的属性，
页面的类型为 fil_page_type_xdes ，它的结构和 fsp_hdr 类型是相似的：

与 fsp_hdr 类型的页面对比，少了 File Space Header 部分，也就是少了记录表空间整体属性的部分，
其余的部分是一样的。

fil_page_ibuf_bitmap 类型

每个分组的第二个页面的类型都是 ibuf_bitmap。
ibuf_bitmap 类型的页记录了一些有关 Change Buffer 的东西。
有关 Change Buffer 的相关知识后面章节介绍。

fil_page_inode 类型

第一个分组的第三个页面的类型是 inode。
设计 InnoDB 的人为每个索引定义了两个段，而且为某些特殊功能定义了些特殊的段。
每个段设有一个 INODE Entry 结构，这个结构中记录了关于这个段的相关属性。
inode 类型的页就是为了存储 INODE Entry 结构而存在的。
inode 类型的页的结构如图所示：

从图中可以看出，一个 inode 类型的页面由这几部分构成，如下表所示：

INODE Entry：前边已经详细介绍过这个结构的组成了，一个页面里可以存储 84 个 INODE Entry 结构。
一个表空间中可能存在超过 84 个段，所以可能一个 inode 类型的页面不足以存储所有的段对应的 INODE Entry 结构，所以就需要超过一个 inode 类型的页面来存储这些 INODE Entry 结构。
为了方便管理 inode 类型的页面，设计 InnoDB 的人将这些 inode 类型的页面串联成两个不同的链表：

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

这两个链表的基节点存储在 fsp_hdr 类型的页面的 File Space Header 部分里边，
也就是说这两个链表的基节点的位置是固定的，所以可以很轻松的访问到这两个链表。
以后每当我们新创建一个段（创建索引时就会创建段）时，都会创建一个 INODE Entry 结构与之对应，
存储 INODE Entry 的大致过程就是这样的：
先看 seg_inodes_free 链表是否为空：

• 如果 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 结构呢？
  所以得找个地方记下段和 INODE Entry 的对应关系。

前面在介绍数据页时，数据页有一个 Page Header 部分
InnoDB 数据页结构

page_btr_seg_leaf 和 page_btr_seg_top ，它们其实对应一个叫 Segment Header 的结构，该结构如表所示：

page_btr_seg_leaf 记录着叶子节点段对应的 INODE Entry 结构在哪个表空间的哪个页面的哪个偏移量，
page_btr_seg_top 记录着非叶子节点段对应的 INODE Entry 结构在哪个表空间的哪个页面的哪个偏移量。这样，索引和其对应的段的关系就建立起来了。
因为一个索引只对应两个段，所以只需要在索引的根页面中记录这两个结构即可。

系统表空间结构

了解完独立表空间的基本结构，系统表空间的结构也就好理解多了，
系统表空间的结构和独立表空间基本类似，只不过由于整个 MySQL 进程只有一个系统表空间，
在系统表空间中会额外记录一些有关整个系统信息的页面，
所以会比独立表空间多出一些记录整个系统信息的页面。
系统表空间的表空间 ID (Space ID) 为 0。

系统表空间与独立表空间的一个明显的不同就是：在表空间开头有许多记录整个系统属性的页面，如图：

可以看到，系统表空间和独立表空间的前三个页面（页号分别为0、1、2，类型分别是 fsp_hdr、ibuf_bitmap、inode）的类型是一致的，
InnoDB 数据页结构

只是页号为 3～7 的页面是系统表空间特有的，页面介绍如下表所示：

系统表空间的 extent1 和 extent2 这两个区，
也就是页号从 64 ~ 127 这 128 个页面被称为 Doublewrite buffer，也就是双写缓冲区。
不过上述的大部分知识都涉及到了事务和多版本控制的问题，这些问题后边的章节集中介绍。
现在只介绍一下有关 InnoDB 数据字典的知识。
InnoDB 数据字典
我们平时使用 insert 语句向表中插入的那些记录称之为用户数据，
MySQL 只是作为一个软件来为我们来保管这些数据，提供方便的增删改查接口而已。
但是每当我们向一个表中插入一条记录的时候，MySQL 要先校验一下插入 insert 语句对应的表是否存在，插入的列和表中的列是否符合，
如果语法没有问题的话，还需要知道该表的聚簇索引和所有二级索引对应的根页面是哪个表空间的哪个页面，然后把记录插入对应索引的 B+ 树中。
所以说，MySQL 除了保存着我们插入的用户数据之外，还需要保存许多额外的信息，比如：

• 某个表属于哪个表空间，该表有多少列
• 表对应的每一个列的数据类型是什么
• 该表有多少个索引，每个索引对应哪几个字段，该索引对应的根页面在哪个表空间的哪个页面
• 该表有哪些外键，外键对应哪个表的哪些列
• 某个表空间对应文件系统上的文件路径是什么
• 等等

上述这些数据并不是我们使用 insert 语句插入的用户数据，
是为了更好的管理我们这些用户数据而不得已引入的一些额外数据，这些数据也称为元数据。
InnoDB 存储引擎特意定义了一些列的内部系统表 (internal system table) 来记录这些元数据：

这些系统表被称为数据字典，系统表都是以 B+ 树的形式保存在系统表空间的某些页面中的，
其中 sys_tables、sys_columns、sys_indexes、sys_fields 这四个表尤其重要，
这四个表被称为基本系统表 (basic system tables)，下面介绍这四个表的结构

sys_tables 表
整个 InnoDB 存储引擎中所有的表的信息

sys_tables 表有两个索引：

• 以 name 列为主键的聚簇索引
• 以 id 列建立的二级索引

sys_columns 表
整个 InnoDB 存储引擎中所有的列的信息

sys_columns 表只有一个聚集索引：

• 以 (table_id, pos) 列为主键的聚簇索引

sys_indexes 表
整个 InnoDB 存储引擎中所有的索引的信息

sys_indexes表只有一个聚集索引：

• 以 (table_id, id) 列为主键的聚簇索引

sys_fields 表
整个 InnoDB 存储引擎中所有的索引对应的列的信息

sys_fields 表只有一个聚集索引：

• 以(INDEX_ID, POS)列为主键的聚簇索引

fil_page_type_sys 类型的页面
只要有了上述 4 个基本系统表，也就意味着可以获取其他系统表以及用户定义的表的所有元数据。
比如：我们想看 sys_tablespaces 系统表里存储了哪些表空间以及表空间对应的属性，那就可以：

• 到 sys_tables 表中根据表名定位到具体的记录，就可以获取到要看的 sys_tablespaces 表的 table_id
• 到 sys_columns 表中根据 table_id，就可以获取到要看的 sys_tablespaces 表的所有列的信息
• 到 sys_indexes 表中根据 table_id，就可以获取到要看的 sys_tablespaces 表的所有索引的信息

索引的信息中包括对应的 index_id，还记录着该索引对应的 B+ 数根页面是哪个表空间的哪个页面。

• 到 sys_fileds 表中根据 index_id，就可以获取到要看索引的所有索引列的信息。

也就是说：这 4 个表是表中之表，那这 4 个表的元数据去哪里获取呢？
只能把这 4 个表的元数据，就是它们有哪些列、哪些索引等信息硬编码到代码中，
然后设计 InnoDB 的人又拿出一个固定的页面来记录这 4 个表的聚簇索引和二级索引对应的 B+ 树位置，
这个页面就是页号为 7 的页面，类型为 fil_page_type_sys，
sys 类型的页面记录了 Data Dictionary Header，也就是数据字典的头部信息。
这个页号为 7 类型为 sys 的页面除了记录这 4 个表的 5 个索引的根页面信息外，
还记录了整个 InnoDB 存储引擎的一些全局属性，这个页面的结构如图所示：

从图中可以看出，这个页面的结构如下表所示：

可以看到这个类型的页面里有 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 表的聚簇索引的根页面的页号。

information_schema 系统数据库
用户是不能直接访问 InnoDB 的这些内部系统表的，
除非你直接去解析系统表空间对应文件系统上的文件。

不过设计 InnoDB 的人考虑到查看这些表的内容可能有助于大家分析问题，
所以在系统数据库 information_schema 中提供了一些以 innodb_sys 开头的表：

我在我的电脑上并没有找到！

在 information_schema 数据库中的这些以 innodb_sys 开头的表并不是真正的内部系统表
（内部系统表就是：上边介绍的以 sys 开头的那些表），而是在存储引擎启动时读取这些以 sys 开头的系统表，然后填充到这些以 innodb_sys 开头的表中。以 innodb_sys 开头的表和以 sys 开头的表中的字段并不完全一样。

总结