通过前边⼉的内容⼤家知道，表空间是⼀个抽象的概念，对于系统表空间来说，对应着⽂件系统中⼀个或多个实际⽂件；对于每个独⽴表空间来说，对应着⽂件系统中⼀个名为表名.ibd的实际⽂件。⼤家可以把表空间想象成被切分为许许多多个⻚的池⼦，当我们想为某个表插⼊⼀条记录的时候，就从池⼦中捞出⼀个对应的⻚来把数据写进去。本章内容会深⼊到表空间的各个细节中，带领⼤家在InnoDB存储结构的池⼦中畅游。
9.1 回忆一些旧知识
9.1.1 页面类型
再⼀次强调，InnoDB是以⻚为单位管理存储空间的，我们的聚簇索引（也就是完整的表数据）和其他的⼆级索引都是以B+树的形式保 存到表空间的，⽽B+树的节点就是数据⻚。我们前边说过，这个数据⻚的类型名其实是：FIL_PAGE_INDEX，除了这种存放索引数据 的⻚⾯类型之外，InnoDB也为了不同的⽬的设计了若⼲种不同类型的⻚⾯，为了唤醒⼤家的记忆，我们再⼀次把各种常⽤的⻚⾯类型提出来：
| 类型名称 | ⼗六进制 | 描述 |
|---|---|---|
| FIL_PAGE_TYPE_ALLOCATED | 0x0000 | 最新分配，还没使⽤ |
| FIL_PAGE_UNDO_LOG | 0x0002 | Undo⽇志⻚ |
| FIL_PAGE_INODE | 0x0003 | 段信息节点 |
| FIL_PAGE_IBUF_FREE_LIST | 0x0004 | Change Buffer空闲列表 |
| FIL_PAGE_IBUF_BITMAP | 0x0005 | Change Buffer的一些属性 |
| FIL_PAGE_TYPE_SYS | 0x0006 | 系统⻚ |
| FIL_PAGE_TYPE_TRX_SYS | 0x0007 | 事务系统数据 |
| FIL_PAGE_TYPE_FSP_HDR | 0x0008 | 表空间头部信息 |
| FIL_PAGE_TYPE_XDES | 0x0009 | 存储区的一些属性 |
| FIL_PAGE_TYPE_BLOB | 0x000A | 溢出页 |
| FIL_PAGE_INDEX | 0x45BF | 索引⻚，也就是我们所说的数据⻚ |
因为⻚⾯类型前边都有个FIL_PAGE或者FIL_PAGE_TYPE的前缀，为简便起⻅我们后边唠叨⻚⾯类型的时候就把这些前缀省略掉了，⽐⽅说FIL_PAGE_TYPE_ALLOCATED类型称为ALLOCATED类型，FIL_PAGE_INDEX类型称为INDEX类型。
9.1.2 ⻚⾯通⽤部分
我们前边说过数据⻚，也就是INDEX类型的⻚由7个部分组成，其中的两个部分是所有类型的⻚⾯都通⽤的。当然我不能寄希望于你把我说的话都记住，所以在这⾥重新强调⼀遍，任何类型的⻚⾯都有下边这种通⽤的结构：
从上图中可以看出，任何类型的⻚都会包含这两个部分：
-
File Header：记录⻚⾯的⼀些通⽤信息
-
File Trailer：校验⻚是否完整，保证从内存到磁盘刷新时内容的⼀致性。
对于File Trailer我们不再做过多强调，全部忘记了的话可以到将数据⻚的那⼀章回顾⼀下。我们这⾥再强调⼀遍File Header的各个组成部分：
| 状态名称 | 占⽤空间⼤⼩ | 描述 |
|---|---|---|
| FIL_PAGE_SPACE_OR_CHKSUM | 4字节 | 当MySQL的版本低于4.0.14时，该属性表示本页面所在的表空间ID；在之后的版本中，该属性表示⻚的校验和（checksum值） |
| FIL_PAGE_OFFSET | 4字节 | ⻚号 |
| FIL_PAGE_PREV | 4字节上⼀个⻚的⻚号 | |
| FIL_PAGE_NEXT | 4字节 | 下⼀个⻚的⻚号 |
| FIL_PAGE_LSN | 8字节 | ⻚⾯被最后修改时对应的LSN⽇志序列位置（英⽂名是：Log Sequence Number） |
| FIL_PAGE_TYPE | 2字节 | 该⻚的类型 |
| FIL_PAGE_FILE_FLUSH_LSN | 8字节 | 仅在系统表空间的⼀个⻚中定义，代表⽂件⾄少被刷新到了对应的LSN值 |
| FIL_PAGE_ARCH_LOG_NO_OR_SPACE_ID | 4字节 | ⻚属于哪个表空间 |
现在除了名称⾥边⼉带有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，我们后边会介绍各种不同类型的⻚，不同类型的⻚在该字段上的值是不同的。
9.2 独立表空间结构
我们知道InnoDB⽀持许多种类型的表空间，本章重点关注独⽴表空间和系统表空间的结构。它们的结构⽐较相似，但是由于系统表空间中额外包含了⼀些关于整个系统的信息，所以我们先挑简单⼀点的独⽴表空间来唠叨，稍后再说系统表空间的结构。
9.2.1 区（extent）的概念
表空间中的⻚实在是太多了，为了更好的管理这些⻚⾯，设计InnoDB的⼤叔们提出了区（英⽂名：extent）的概念。对于16KB 的⻚来说，连续的64个⻚就是⼀个区，也就是说⼀个区默认占⽤1MB空间⼤⼩。不论是系统表空间还是独⽴表空间，都可以看成是由若⼲个区组成的，每256个区被划分成⼀组。画个图表示就是这样：
其中extent 0 ~ extent 255这256个区算是第⼀个组，extent256 ~ 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个⻚⾯的类型是固定的，也就是说extent256、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个区划分为⼀组，每个组的最开始的⼏个⻚⾯类型是固定的就好了。
9.2.2 段（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个碎⽚区⻚⾯之后，就会以完整的区为单位来分配存储空间。(原先占用的碎片区页面并不会被复制到新申请的完整的区中)
所以现在段不能仅定义为是某些区的集合，更精确的应该是某些零散的⻚⾯以及⼀些完整的区的集合。除了索引的叶⼦节点段和⾮叶⼦节点段之外，InnoDB中还有为存储⼀些特殊的数据⽽定义的段，⽐如回滚段，当然我们现在并不关⼼别的类型的段，现在只需要知道段是⼀些零散的⻚⾯以及⼀些完整的区的集合就好了。
9.2.3 区的分类
通过上边⼀通唠叨，⼤家知道了表空间的是由若⼲个区组成的，这些区⼤体上可以分为4种类型：
-
空闲的区：现在还没有⽤到这个区中的任何⻚⾯。
-
有剩余空间的碎⽚区：表示碎⽚区中还有可⽤的⻚⾯。
-
没有剩余空间的碎⽚区：表示碎⽚区中的所有⻚⾯都被使⽤，没有空闲⻚⾯。
-
附属于某个段的区。每⼀个索引都可以分为叶⼦节点段和⾮叶⼦节点段，除此之外InnoDB 还会另外定义⼀些特殊作⽤的段，在这些段中的数据量很⼤时将使⽤区来作为基本的分配单位，这些区中的页面完全用于存储该段中的数据（而碎片区可以存储属于不同段的数据）。
这4种类型的区也可以被称为区的4种状态（State），设计InnoDB的⼤叔们为这4种状态的区定义了特定的名词⼉：
| 状态名 | 含义 |
|---|---|
| FREE | 空闲的区 |
| FREE_FRAG | 有剩余空间的碎⽚区 |
| FULL_FRAG | 没有剩余空间的碎⽚区 |
| FSEG | 附属于某个段的区 |
需要再次强调⼀遍的是，处于FREE、FREE_FRAG以及FULL_FRAG这三种状态的区都是独⽴的，算是直属于表空间；⽽处于FSEG状态的区是附属于某个段的。
-
小贴士
-
如果把表空间⽐作是⼀个集团军，段就相当于师，区就相当于团。⼀般的团都是⾪属于某个师的，就像是处于
FSEG的区全都⾪属于某个段，⽽处于FREE、FREE_FRAG以及FULL_FRAG这三种状态的区却直接⾪属于表空间，就像独⽴团直接听命于军部⼀样。
为了⽅便管理这些区，设计InnoDB的⼤叔设计了⼀个称为XDESEntry的结构（全称就是Extent Descriptor Entry），每⼀个区都对应着⼀个XDES Entry结构，这个结构记录了对应的区的⼀些属性。我们先看图来对这个结构有个⼤致的了解：
从图中我们可以看出，XDES Entry是⼀个40个字节的结构，⼤致分为4个部分，各个部分的释义如下：
-
Segment ID（8字节）
每⼀个段都有⼀个唯⼀的编号，⽤ID表示，此处的SegmentID字段表示就是该区所在的段。当然前提是该区已经被分配给某个段了，不然的话该字段的值没啥意义。
-
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 StateBitmap部分的第1和第2个⽐特位对应着区中的第1个⻚⾯，第3和第4个⽐特位对应着区中的第2个⻚⾯，依此类推，PageState Bitmap部分的第127和128个⽐特位对应着区中的第64个⻚⾯。这两个⽐特位的第⼀个位表示对应的⻚是否是空闲的，第⼆个⽐特位还没有⽤。
XDES Entry链表
到现在为⽌，我们已经提出了五花⼋⻔的概念，什么区、段、碎⽚区、附属于段的区、XDES Entry结构吧啦吧啦的概念，⾛远了千万别忘了⾃⼰为什么出发，我们把事情搞这么麻烦的初⼼仅仅是想提⾼向表插⼊数据的效率⼜不⾄于数据量少的表浪费空间。现在我们知道向表中插⼊数据本质上就是向表中各个索引的叶⼦节点段、⾮叶⼦节点段插⼊数据，也知道了不同的区有不同的状态，再回到最初的起点，捋⼀捋向某个段中插⼊数据的过程：
- 当段中数据较少的时候，⾸先会查看表空间中是否有状态为FREE_FRAG的区，也就是找还有空闲空间的碎⽚区，如果找到了，那么从该区中取⼀些零碎的⻚把数据插进去；否则到表空间下申请⼀个状态为FREE的区，也就是空闲的区，把该区的状态变为FREE_FRAG，然后从该新申请的区中取⼀些零碎的⻚把数据插进去。之后不同的段使⽤零碎⻚的时候都会从该区中取，直到该区中没有空闲空间，然后该区的状态就变成了FULL_FRAG。
现在的问题是你怎么知道表空间⾥的哪些区是FREE的，哪些区的状态是FREE_FRAG的，哪些区是FULL_FRAG的？要知道表空间的⼤⼩是可以不断增⼤的，当增⻓到GB级别的时候，区的数量也就上千了，我们总不能每次都遍历这些区对应的XDESEntry结构吧？这时候就是XDES Entry中的List Node部分发挥奇效的时候了，我们可以通过List Node中的指针，做这么三件事：
-
把状态为FREE的区对应的XDES Entry结构通过ListNode来连接成⼀个链表，这个链表我们就称之为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个零散的⻚后，就直接申请完整的区来插⼊数据了。
还是那个问题，我们怎么知道哪些区属于哪个段的呢？再遍历各个XDES Entry结构？遍历是不可能遍历的，这辈⼦都不可能遍历的，有链表还遍历个⽑线啊。所以我们把状态为FSEG的区对应的XDES Entry结构都加⼊到⼀个链表喽？傻呀，不同的段哪能共⽤⼀个区呢？你想把表a的聚簇索引的叶⼦节点段和表b的聚簇索引的叶⼦节点段都存储到⼀个区中么？显然我们想要每个段都有它独⽴的链表，所以可以根据段号（也就是Segment ID）来建⽴链表，有多少个段就建多少个链表？好像也有点问题，因为⼀个段中可以有好多个区，有的区是完全空闲的，有的区还有⼀些⻚⾯可以⽤，有的区已经没有空闲⻚⾯可以⽤了，所以我们有必要继续细分，设计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个链表，整个独立表空间共需要维护15个链表。
所以段在数据量⽐较⼤时插⼊数据的话，会先获取NOT_FULL链表的头节点，直接把数据插⼊这个头节点对应的区中即可，如果该区的空间已经被⽤完，就把该节点移到FULL链表中。
链表基节点
上边光是介绍了⼀堆链表，可我们怎么找到这些链表呢，或者说怎么找到某个链表的头节点或者尾节点在表空间中的位置呢？设计InnoDB的⼤叔当然考虑了这个问题，他们设计了⼀个叫List BaseNode的结构，翻译成中⽂就是链表的基节点。这个结构中包含了链表的头节点和尾节点的指针以及这个链表中包含了多少节点的信息，我们画图看⼀下这个结构的示意图：
我们上边介绍的每个链表都对应这么⼀个List Base Node结构，其中：
-
List Length表明该链表⼀共有多少节点，
-
First Node Page Number和First Node Offset表明该链表的头节点在表空间中的位置。
-
Last Node Page Number和Last Node Offset表明该链表的尾节点在表空间中的位置。
⼀般我们把某个链表对应的List Base Node结构放置在表空间中固定的位置，这样想找定位某个链表就变得so easy啦。
链表小结
综上所述，表空间是由若⼲个区组成的，每个区都对应⼀个XDESEntry的结构，直属于表空间的区对应的XDES Entry结构可以分成FREE、FREE_FRAG和FULL_FRAG这3个链表；每个段可以拥有若⼲个区，每个段中的区对应的XDES Entry结构可以分成FREE、NOT_FULL和FULL这3个链表。每个链表都对应⼀个ListBase Node的结构，这个结构⾥记录了链表的头、尾节点的位置以及该链表中包含的节点数。正是因为这些链表的存在，管理这些区才变成了⼀件so easy的事情。
9.2.4 段的结构
我们前边说过，段其实不对应表空间中某⼀个连续的物理区域，⽽是⼀个逻辑上的概念，由若⼲个零散的⻚⾯以及⼀些完整的区组成。像每个区都有对应的XDES Entry来记录这个区中的属性⼀样，设计InnoDB的⼤叔为每个段都定义了⼀个INODE Entry结构来记录⼀下段中的属性。⼤家看⼀下示意图：
它的各个部分释义如下：
-
Segment ID
就是指这个INODE Entry结构对应的段的编号（ID）。
-
NOT_FULL_N_USED
这个字段指的是在NOT_FULL链表各XDES Entry节点对应的区已经使⽤了多少⻚⾯。⼀个区中有64个⻚⾯，如果不标记已经使⽤了多少⻚⾯的话，每次向段中插⼊数据的时候都要从第⼀个⻚⾯进⾏遍历寻找空闲⻚⾯，有了这个字段之后就可以快速定位空闲⻚⾯。
-
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结构，⼤家可能对段是⼀些零散⻚⾯和⼀些完整的区的集合的理解再次深刻⼀些。
9.2.5 各类型界面的使用情况
到现在为⽌我们已经⼤概清楚了表空间、段、区、XDES Entry、INODE Entry、各种以XDES Enty为节点的链表的基本概念了，可是总有⼀种⻜在天上不踏实的感觉，每个区对应的XDES Entry结构到底存储在表空间的什么地⽅？直属于表空间的FREE、FREE_FRAG、FULL_FRAG链表的基节点到底存储在表空间的什么地⽅？每个段对应的INODE Entry结构到底存在表空间的什么地⽅？我们前边介绍了每256个连续的区算是⼀个组，想解决刚才提出来的这些个疑问还得从每个组开头的⼀些类型相同的⻚⾯说起，接下来我们⼀个⻚⾯⼀个⻚⾯的分析，真相⻢上就要浮出⽔⾯了。
1.FSP_HDR类型
⾸先看第⼀个组的第⼀个⻚⾯，当然也是表空间的第⼀个⻚⾯，⻚号为0。这个⻚⾯的类型是FSP_HDR，它存储了表空间的⼀些整体属性以及第⼀个组内256个区的对应的XDES Entry结构，直接看这个类型的⻚⾯的示意图：
⾸先看第⼀个组的第⼀个⻚⾯，当然也是表空间的第⼀个⻚⾯，⻚号为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 Header和File Trailer就不再强调了，另外的⼏个部分中，Empty Space是尚未使⽤的空间，我们不⽤管它，重点来看看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链表的基节点 |
这⾥头的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类型的⻚⾯）的FileSpace Header部分。所以之后定位这⼏个链表就so easy 啦。
-
FRAG_N_USED
这个字段表明在FREE_FRAG链表中已经使⽤的⻚⾯数量，⽅便之后在链表中查找空闲的⻚⾯。
-
FREE Limit
我们知道表空间都对应着具体的磁盘⽂件，⼀开始我们创建表空间的时候对应的磁盘⽂件中都没有数据，所以我们需要对表空间完成⼀个初始化操作，包括为表空间中的区建⽴XDESEntry结构，为各个段建⽴INODE Entry结构，建⽴各种链表吧啦吧啦的各种操作。我们可以⼀开始就为表空间申请⼀个特别⼤的空间，但是实际上有绝⼤部分的区是空闲的，我们可以选择把所有的这些空闲区对应的XDES Entry结构加⼊FREE链表，也可以选择只把⼀部分的空闲区加⼊FREE链表，等啥时候空闲链表中的XDES Entry结构对应的区不够使了，再把之前没有加⼊FREE链表的空闲区对应的XDES Entry结构加⼊FREE链表，中⼼思想就是啥时候⽤到啥时候初始化，设计InnoDB的⼤叔采⽤的就是后者，他们为表空间定义了FREELimit这个字段，在该字段表示的⻚号之前的区都被初始化了，之后的区尚未被初始化。
-
Next Unused Segment ID
表中每个索引都对应2个段，每个段都有⼀个唯⼀的ID，那当我们为某个表新创建⼀个索引的时候，就意味着要创建两个新的段。那怎么为这个新创建的段找⼀个唯⼀的ID呢？去遍历现在表空间中所有的段么？我们说过，遍历是不可能遍历的，这辈⼦都不可能遍历，所以设计InnoDB的⼤叔们提出了这个名叫Next Unused Segment ID的字段，该字段表明当前表空间中最⼤的段ID的下⼀个ID，这样在创建新段的时候赋予新段⼀个唯⼀的ID值就so easy啦，直接使⽤这个字段的值就好了。
-
Space Flags
表空间对于⼀些布尔类型的属性，或者只需要寥寥⼏个⽐特位搞定的属性都放在了这个Space Flags中存储，虽然它只有4 个字节，32个⽐特位⼤⼩，却存储了好多表空间的属性，详细情况如下表：
| 标志名称 | 占⽤的空间（单位：bit） | 描述 |
|---|---|---|
| POST_ANTELOPE | 1 | 表示⽂件格式是否在ANTELOPE格式之后 |
| ZIP_SSIZE | 4 | 表示压缩⻚⾯的⼤⼩ |
| ATOMIC_BLOBS | 1 | 表示是否⾃动把值⾮常⻓的字段放到溢出⻚⾥ |
| PAGE_SSIZE | 4 | ⻚⾯⼤⼩ |
| DATA_DIR | 1 | 表示表空间是否是从默认的数据⽬录中获取的 |
| SHARED | 1 | 是否为共享表空间 |
| TEMPORARY | 1 | 是否为临时表空间 |
| ENCRYPTION | 1 | 表空间是否加密 |
| UNUSED | 18 | 没有使⽤到的⽐特位 |
-
⼩贴⼠
- 不同MySQL版本⾥ SPACE_FLAGS 代表的属性可能有些差异，我们这⾥列举的是5.7.21版本的。不过⼤家现在不必深究它们的意思，因为我们⼀旦把这些概念展开，就需要⾮常⼤的篇幅，主要怕⼤家受不了。我们还是先挑重要的看，把主要的表空间结构了解完，这些 SPACE_FLAGS ⾥的属性的细节就暂时不深究了。
-
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类型的⻚之后再回过头来看着两个链表。
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就对应着extent255。
因为每个区对应的XDES Entry结构的地址是固定的，所以我们访问这些结构就so easy啦，⾄于该结构的详细使⽤情况我们已经唠叨的够明⽩了，在这就不赘述了。
2.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类型的⻚⾯也就不重复唠叨了哈。
3.IBUF_BITMAP类型
对比前文介绍的图，每个分组中的第二个页面的类型都是IBUF_BITMAP。这种类型的页中记录了一些有关Change Buffer的东西。
我们平时说向表中插入一条记录，其实本质上是向每个索引对应的B+树中插入记录。该记录首先插入聚簇索引页面，然后再插入每个二级索引页面。这些页面在表空间中随机分布，将会产生大量的随机IO，严重影响性能。对于UPDATE和DELETE操作来说，也会带来许多的随机IO。所以设计InnoDB的大叔引入了一种称为Change Buffer的结构（本质上也是表空间中的一颗B+树，它的根节点在系统表空间中）。在修改非唯一二级索引页面时（修改唯一二级索引页面时是否利用Change Buffer取决于很多情况，我们这里就不展开讨论了），如果该页面尚未被加载到内存中（仍在磁盘上），那么该修改将先被暂时缓存到Change Buffer中，之后服务器空闲或者其他什么原因导致对应的页面从磁盘上加载到内存中时，再将修改合并到对应页面。另外，在很久之前的版本中只会缓存INSERT操作对二级索引页面所做的修改，所以Change Buffer以前被称作Insert Buffer，所以在各种命名上延续了之前的叫法，比方说IBUF其实是Insert Buffer的缩写。
4.INODE类型
再次对⽐前边介绍表空间的图，第⼀个分组的第三个⻚⾯的类型是INODE。我们前边说过设计InnoDB的⼤叔为每个索引定义了两个段，⽽且为某些特殊功能定义了些特殊的段。为了⽅便管理，他们⼜为每个段设计了⼀个INODE Entry结构，这个结构中记录了关于这个段的相关属性。⽽我们这会⼉要介绍的这个INODE类型的⻚就是为了存储INODE Entry结构⽽存在的。好了，废话少说，直接看图：
从图中可以看出，⼀个INODE类型的⻚⾯是由这⼏部分构成的：
| 名称 | 中⽂名 | 占⽤空间⼤⼩ | 简单描述 |
|---|---|---|---|
| File Header | ⽂件头部 | 38字节 | ⻚的⼀些通⽤信息 |
| List Node for INODE Page List | 通⽤链表节点 | 12字节 | 存储上⼀个INODE⻚⾯和下⼀个INODE⻚⾯的指针 |
| INODE Entry | 段描述信息 | 16320字节 | 具体的INODE Entry结构 |
| 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这个玩意⼉，因为⼀个表空间中可能存在超过84个段，所以可能⼀个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结构放⼊该⻚⾯。
9.2.6 Segment Header 结构的运⽤
我们知道⼀个索引会产⽣两个段，分别是叶⼦节点段和⾮叶⼦节点段，⽽每个段都会对应⼀个INODE Entry结构，那我们怎么知道某个段对应哪个INODE Entry结构呢？所以得找个地⽅记下来这个对应关系。希望你还记得我们在唠叨数据⻚，也就是INDEX类型的⻚时有⼀个Page Header部分，当然我不能指望你记住，所以把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 Entry | 2 | INODE Entry结构在该⻚⾯中的偏移量 |
这样⼦就很清晰了，PAGE_BTR_SEG_LEAF记录着叶⼦节点段对应的INODE Entry结构的地址是哪个表空间的哪个⻚⾯的哪个偏移量，PAGE_BTR_SEG_TOP记录着⾮叶⼦节点段对应的INODE Entry结构的地址是哪个表空间的哪个⻚⾯的哪个偏移量。这样⼦索引和其对应的段的关系就建⽴起来了。不过需要注意的⼀点是，因为⼀个索引只对应两个段，所以只需要在索引的根⻚⾯中记录这两个结构即可。
9.2.7 真实表空间对应的⽂件⼤⼩
等会⼉等会⼉，上边的这些概念已经压的快喘不过⽓了。不过独⽴表空间有那么⼤么？我到数据⽬录⾥看了，⼀个新建的表对应的.ibd⽂件只占⽤了96K，才6个⻚⾯⼤⼩，上边的内容该不是扯犊⼦吧？
哈，⼀开始表空间占⽤的空间⾃然是很⼩，因为表⾥边都没有数据嘛！不过别忘了这些.ibd⽂件是⾃扩展的，随着表中数据的增多，表空间对应的⽂件也逐渐增⼤。
9.3 系统表空间
了解完了独⽴表空间的基本结构，系统表空间的结构也就好理解多了，系统表空间的结构和独⽴表空间基本类似，只不过由于整个MySQL进程只有⼀个系统表空间，在系统表空间中会额外记录⼀些有关整个系统信息的⻚⾯，所以会⽐独⽴表空间多出⼀些记录这些信息的⻚⾯。因为这个系统表空间最⽜逼，相当于是表空间之⾸，所以它的表空间 ID（Space ID）是0。
9.3.1 系统表空间的整体结构
系统表空间与独⽴表空间的⼀个⾮常明显的不同之处就是在表空间开头有许多记录整个系统属性的⻚⾯，如图：
可以看到，系统表空间和独⽴表空间的前三个⻚⾯（⻚号分别为0、1、2，类型分别是FSP_HDR、IBUF_BITMAP、INODE）的类型是⼀致的，只是⻚号为3～7的⻚⾯是系统表空间特有的，我们来看⼀下这些多出来的⻚⾯都是⼲啥使的：
| ⻚号 | ⻚⾯类型 | 英⽂描述 | 描述 |
|---|---|---|---|
| 3 | SYS | Insert Buffer Header | 存储Change Buffer的头部信息 |
| 4 | INDEX | Insert Buffer Root | 存储Change 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数据字典的知识，其余的概念在后边再看。
InnoDB数据字典
我们平时使⽤INSERT语句向表中插⼊的那些记录称之为⽤户数据，MySQL只是作为⼀个软件来为我们来保管这些数据，提供⽅便的增删改查接⼝⽽已。但是每当我们向⼀个表中插⼊⼀条记录的时候，MySQL先要校验⼀下插⼊语句对应的表存不存在，插⼊的列和表中的列是否符合，如果语法没有问题的话，还需要知道该表的聚簇索引和所有⼆级索引对应的根⻚⾯是哪个表空间的哪个⻚⾯，然后把记录插⼊对应索引的B+树中。所以说，MySQL除了保存着我们插⼊的⽤户数据之外，还需要保存许多额外的信息，⽐⽅说：
- 某个表属于哪个表空间，表⾥边有多少列
- 表对应的每⼀个列的类型是什么
- 该表有多少索引，每个索引对应哪⼏个字段，该索引对应的根⻚⾯在哪个表空间的哪个⻚⾯
- 该表有哪些外键，外键对应哪个表的哪些列
- 某个表空间对应⽂件系统上⽂件路径是什么
- balabala … 还有好多，不⼀⼀列举了
上述这些数据并不是我们使⽤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表
| 列名 | 描述 |
|---|---|
| NAME | 表的名称 |
| ID | InnoDB存储引擎中每个表都有⼀个唯⼀的ID |
| N_COLS | 该表拥有列的个数 |
| TYPE | 表的类型，记录了⼀些⽂件格式、⾏格式、压缩等信息 |
| MIX_ID | 已过时，忽略 |
| MIX_LEN | 表的⼀些额外的属性 |
| CLUSTER_ID | 未使⽤，忽略 |
| SPACE | 该表所属表空间的ID |
这个SYS_TABLES表有两个索引：
- 以NAME列为主键的聚簇索引
- 以ID列建⽴的⼆级索引
SYS_COLUMNS表
| 列名 | 描述 |
|---|---|
| TABLE_ID | 该列所属表对应的ID |
| POS | 该列在表中是第⼏列 |
| NAME | 该列的名称 |
| MTYPE | main data type，主数据类型，就是那堆INT、CHAR、VARCHAR、FLOAT、DOUBLE之类的东东 |
| PRTYPE | precise type，精确数据类型，就是修饰主数据类型的那堆东东，⽐如是否允许NULL值，是否允许负数啥的 |
| LEN | 该列最多占⽤存储空间的字节数 |
| PREC | 该列的精度，不过这列貌似都没有使⽤，默认值都是0 |
这个SYS_COLUMNS表只有⼀个聚集索引：
- 以(TABLE_ID, POS)列为主键的聚簇索引
SYS_INDEXES表
| 列名 | 描述 |
|---|---|
| TABLE_ID | 该索引所属表对应的ID |
| ID | InnoDB存储引擎中每个索引都有⼀个唯⼀的ID |
| NAME | 该索引的名称 |
| N_FIELDS | 该索引包含列的个数 |
| TYPE | 该索引的类型，⽐如聚簇索引、唯⼀索引、更改缓冲区的索引、全⽂索引、普通的⼆级索引等等各种类型 |
| SPACE | 该索引根页面所在的表空间ID |
| PAGE_NO | 该索引根页面所在的页面号 |
| MERGE_THRESHOLD | 如果⻚⾯中的记录被删除到某个⽐例，就把该⻚⾯和相邻⻚⾯合并，这个值就是这个⽐例 |
这个SYS_INEXES表只有⼀个聚集索引：
- 以(TABLE_ID, ID)列为主键的聚簇索引
SYS_FIELDS表
| 列名 | 描述 |
|---|---|
| INDEX_ID | 该索引列所属的索引的ID |
| POS | 该索引列在某个索引中是第⼏列 |
| COL_NAME | 该索引列的名称 |
这个SYS_INEXES表只有⼀个聚集索引：
- 以(INDEX_ID, 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存储引擎的⼀些全局信息 |
| Unused | 未使用 | 4字节 | 未使用 |
| Segment Header | 段头部信息 | 10字节记录本⻚⾯所在段对应的INODEEntry位置信息 | |
| 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，也就是说这个MaxRow ID是全局共享的。
-
小贴士
- 当然并不是每分配一个row_id值都会将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表聚簇索引的根⻚⾯的⻚号。
以上就是⻚号为7的⻚⾯的全部内容，初次看可能会懵逼（因为有点
⼉绕），⼤家多瞅⼏次。
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开头的表中的字段并不完全⼀样，但供⼤家参考已经⾜矣。这些表太多了，我就不唠叨了，⼤家⾃个⼉动⼿试着查⼀查这些表中的数据吧哈～