一、系统表空间结构
了解完了独立表空间的基本结构，系统表空间的结构也就好理解多了，系统表空间的结构和独立表空间基本类似，只不过由于整个MySQL进程只有一个系统表空间，在系统表空间中会额外记录一些有关整个系统信息的页面，所以会比独立表空间多出一些记录这些信息的页面。因为这个系统表空间最厉害，相当于是表空间之首，所以它的表空间 ID（Space ID）是0。
1.1 系统表空间整体结构
系统表空间与独立表空间的一个非常明显的不同之处就是在表空间开头有许多记录整个系统属性的页面，如图：
可以看到，系统表空间和独立表空间的前三个页面（页号分别为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，也就是双写缓冲区，哈哈，还有印象吗？如果没有了，请移步MySQL之Doublewrite Buffer
1.2 Data Dictionary Header页面
InnoDB存储引擎特意定义了一些列的内部系统表（Internal System Table）来记录元数据，这些系统表也被称为数据字典，它们都是以B+树的形式保存在系统表空间的某些页面中，其中SYS_TABLES、SYS_COLUMNS、SYS_INDEXES、SYS_FIELDS这四个表尤其重要，称之为基本系统表（Basic System Tables）。只要有了上述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 Dictionary Header，也就是数据字典的头部信息。除了这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个字节没用，跳过。
以上就是页号为7的页面的全部内容，看一次肯定懵，一定要反复多看几次。
二、总结
今天我们学习了关于InnoDB存储引擎表空间的结构，通篇几乎全是概念、图片，这部分知识本就枯燥乏味，但是’春天’马上就到来，最枯燥乏味的内容马上结束了。由于今天的内容都是偏理论的概念，加上篇幅原因，就不做知识点总结了。
今天的文章我第一次读原著时，一脸懵逼，好像知道了表空间结构是怎么一回事儿，但是好像又讲不出来什么，所以建议大家多看几次，我相信一句话：书读百遍，其义自见。当你一次看不懂的时候，就一定要多看几次。同时，建议大家多动手画一画结构图，这样理解起来更加深刻。
通过本文的学习，知道了MySQL数据库设计之复杂、精妙。原书作者小孩子4919大佬钻研技术的深度，是我目前所不能及的，所以，跟紧大佬的步伐，每天进步一点点，愿大家终将都会成为别人眼中的大佬，共勉！
