一文带你了解MySQL之InnoDB表空间

一、回忆一些旧知识

1.1 页面的类型

在这里再次强调一下，InnoDB是以页为单位管理存储空间的，我们的聚簇索引（也就是完整的表数据）和其他的二级索引都是以B+树的形式保存到表空间的，而B+树的节点就是数据页。我们前边说过，这个数据页的类型名其实是：fil_page_index。除了这种存放索引数据的页面类型之外，InnoDB也为了不同的目的设计了若干种不同类型的页面，下面这张表相信大家一定很熟悉了：

因为页面类型前边都有个fil_page或者fil_page_type的前缀，为简便起见我们后边讲解页面类型的时候就把这些前缀省略掉了，比方说fil_page_type_allocated类型称为allocated类型，fil_page_index类型称为index类型等

1.2 页面的通用部分

我们在之前文章MySQL之数据页结构中说过数据页，也就是index类型的页由7个部分组成，其中的两个部分是所有类型的页面都通用的（当然我不能寄希望于你把我说的话都记住，所以在这里重新强调一遍）任何类型的页面都有下边这种通用的结构：

从上图中可以看出，任何类型的页都会包含这两个部分：

File Header：记录页面的一些通用信息

File Trailer：校验页是否完整，保证从内存到磁盘刷新时内容的一致性。

对于File Trailer我们不再做过多强调，我们这里再强调一遍File Header的各个组成部分：

现在除了名称里边儿带有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，我们后边会介绍各种不同类型的页，不同类型的页在该字段上的值是不同的

二、独立的表空间

我们知道InnoDB支持许多种类型的表空间，本文重点关注独立表空间和系统表空间的结构。它们的结构比较相似，但是由于系统表空间中额外包含了一些关于整个系统的信息，所以我们先挑简单一点的独立表空间来介绍，稍后再说系统表空间的结构

2.1 区（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类型的页面其实和XDES类型的页面的作用类似，只不过FSP_HDR类型的页面还会额外存储一些表空间的属性。

IBUF_BITMAP类型：同上，此处不再讲解。

宏观的结构就是这样了，里边的名词大家也不用记的太清楚，只要大致记得：表空间被划分为许多连续的区，每个区默认由64个页组成，每256个区划分为一组，每个组的最开始的几个页面类型是固定的就好了

2.2 段（Segment）的概念

如果我们表中数据量很少的话，如你的表中只有几十条、几百条数据的话，的确用不到区的概念，因为简单的几个页就能把对应的数据存储起来，但是后期你架不住表里的记录越来越多。

从理论上说，不引入区的概念只使用页的概念对存储引擎的运行并没啥影响，但是我们来考虑一下下边这个场景：

我们每向表中插入一条记录，本质上就是向该表的聚簇索引以及所有二级索引代表的B+树的节点中插入数据。而B+树的每一层中的页都会形成一个双向链表，如果是以页为单位来分配存储空间的话，双向链表相邻的两个页之间的物理位置可能离得非常远。我们介绍B+树索引的适用场景的时候特别提到范围查询只需要定位到最左边的记录和最右边的记录，然后沿着双向链表一直扫描就可以了，而如果链表中相邻的两个页物理位置离得非常远，就是所谓的随机I/O。

小提示：

磁盘的速度和内存的速度差了好几个数量级，随机I/O是非常慢的，所以我们应该尽量让链表中相邻的页的物理位置也相邻，这样进行范围查询的时候才可以使用所谓的顺序I/O。

所以才引入了区（extent）的概念，一个区就是在物理位置上连续的64个页（1M）。在表中数据量大的时候，为某个索引分配空间的时候就不再按照页为单位分配了，而是按照区为单位分配，甚至在表中的数据十分非常特别多的时候，可以一次性分配多个连续的区。虽然可能造成一点点空间的浪费（数据不足填充满整个区），但是从性能角度看，可以消除很多的随机I/O，功大于过。

我们提到的范围查询，其实是对B+树叶子节点中的记录进行顺序扫描，而如果不区分叶子节点和非叶子节点，统统把节点代表的页面放到申请到的区中的话，进行范围扫描的效果就大打折扣了。所以InnoDB对B+树的叶子节点和非叶子节点进行了区别对待，也就是说叶子节点有自己独有的区，非叶子节点也有自己独有的区。存放叶子节点的区的集合就算是一个段（segment），存放非叶子节点的区的集合也算是一个段。也就是说一个索引会生成2个段，一个叶子节点段，一个非叶子节点段。

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

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

在刚开始向表中插入数据的时候，段是从某个碎片区以单个页面为单位来分配存储空间的

当某个段已经占用了32个碎片区页面之后，就会以完整的区为单位来分配存储空间

所以现在段不能仅定义为是某些区的集合，更精确的应该是某些零散的页面以及一些完整的区的集合。除了索引的叶子节点段和非叶子节点段之外，InnoDB中还有为存储一些特殊的数据而定义的段，比如回滚段，当然我们现在并不关心别的类型的段，现在只需要知道段是一些零散的页面以及一些完整的区的集合就好了。

2.3 区的分类

表空间的是由若干个区组成的，这些区大体上可以分为4种类型：

空闲的区：现在还没有用到这个区中的任何页面。

有剩余空间的碎片区：表示碎片区中还有可用的页面。

没有剩余空间的碎片区：表示碎片区中的所有页面都被使用，没有空闲页面。

附属于某个段的区：每一个索引都可以分为叶子节点段和非叶子节点段，除此之外InnoDB还会另外定义一些特殊作用的段，在这些段中的数据量很大时将使用区来作为基本的分配单位。

这4种类型的区也可以被称为区的4种状态（State），InnoDB为这4种状态的区定义了特定的名词：

需要再次强调一遍的是，处于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的结构：

如果我们想定位表空间内的某一个位置的话，只需指定页号以及该位置在指定页号中的页内偏移量即可。所以：

Prev Node Page Number和Prev 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字节）

这个部分共占用16个字节，也就是128个比特位。我们说一个区默认有64个页，这128个比特位被划分为64个部分，每个部分2个比特位，对应区中的一个页。比如Page State Bitmap部分的第1和第2个比特位对应着区中的第1个页面，第3和第4个比特位对应着区中的第2个页面，依此类推，Page State Bitmap部分的第127和128个比特位对应着区中的第64个页面。这两个比特位的第一个位表示对应的页是否是空闲的，第二个比特位还没有用

2.4 XDES Entry链表

到现在为止，我们已经提出了区、段、碎片区、附属于段的区、XDES Entry等概念，我们把事情搞这么麻烦的初心仅仅是想提高向表插入数据的效率又不至于数据量少的表浪费空间。现在我们知道向表中插入数据本质上就是向表中各个索引的叶子节点段、非叶子节点段插入数据，也知道了不同的区有不同的状态，再回到最初的起点，捋一捋向某个段中插入数据的过程：

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

现在的问题是你怎么知道表空间里的哪些区是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，然后从这个节点对应的区中获取零散的页就好了。

当段中数据已经占满了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 demo9 (c1 int not null auto_increment,c2 varchar(100),c3 varchar(100),primary key (c1), key idx_c2 (c2));

1

这个表t共有两个索引，一个聚簇索引，一个二级索引idx_c2，所以这个表共有4个段，每个段都会维护上述3个链表，总共是12个链表，加上我们上边说过的直属于表空间的3个链表，整个独立表空间共需要维护15个链表。所以段在数据量比较大时插入数据的话，会先获取not_full链表的头节点，直接把数据插入这个头节点对应的区中即可，如果该区的空间已经被用完，就把该节点移到full链表中。

2.4.1 链表基节点

上边介绍了很多链表，怎么找到这些链表呢，或者说怎么找到某个链表的头节点或者尾节点在表空间中的位置呢？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结构放置在表空间中固定的位置，这样想找定位某个链表就变得非常简单啦。

2.4.2 链表小结

综上所述，表空间是由若干个区组成的，每个区都对应一个XDES Entry的结构，直属于表空间的区对应的XDES Entry结构可以分成free、free_frag和full_frag这3个链表；每个段可以附属若干个区，每个段中的区对应的XDES Entry结构可以分成free、not_full和full这3个链表。每个链表都对应一个List Base Node的结构，这个结构里记录了链表的头、尾节点的位置以及该链表中包含的节点数。正是因为这些链表的存在，管理这些区才变成了一件非常简单的事情。

2.4.3 段的结构

我们前边说过，段其实不对应表空间中某一个连续的物理区域，而是一个逻辑上的概念，由若干个零散的页面以及一些完整的区组成。像每个区都有对应的XDES Entry来记录这个区中的属性一样，InnoDB为每个段都定义了一个INODE Entry结构来记录一下段中的属性。大家看一下示意图：

它的各个部分释义如下：

Segment ID

就是指这个INODE Entry结构对应的段的编号（ID）。

NOT_FULL_N_USED

这个字段指的是在NOT_FULL链表中已经使用了多少个页面。

3个List Base Node

分别为段的free链表、not_null链表、full链表定义了List Base Node，这样我们想查找某个段的某个链表的头节点和尾节点的时候，就可以直接到这个部分找到对应链表的List Base Node。

Magic Number

这个值是用来标记这个INODE Entry是否已经被初始化了（初始化的意思就是把各个字段的值都填进去了）。如果这个数字是值的97937874，表明该INODE Entry已经初始化，否则没有被初始化。（不用纠结这个值有啥特殊含义，规定）。

Fragment Array Entry

段是一些零散页面和一些完整的区的集合，每个Fragment Array Entry结构都对应着一个零散的页面，这个结构一共4个字节，表示一个零散页面的页号。

结合着这个INODE Entry结构，大家可能对段是一些零散页面和一些完整的区的集合的理解再次深刻一些

2.4.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 Header和File Trailer就不再强调了，另外的几个部分中，Empty Space是尚未使用的空间，我们不用管它，重点来看看File Space Header和XDES Entry这两个部分。

File Space Header部分

这个部分是用来存储表空间的一些整体属性信息的，详看下图：

下面是各个属性的简单描述：

这里头的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类型的页面）的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提出了这个名叫Next Unused Segment ID的字段，该字段表明当前表空间中最大的段ID的下一个ID，这样在创建新段的时候赋予新段一个唯一的ID值就so easy啦，直接使用这个字段的值就好了。

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结构。

由于我们现在还没有详细介绍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就对应着extent 255。

因为每个区对应的XDES Entry结构的地址是固定的，所以我们访问这些结构就非常简单啦。

2.4.5 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部分之外，也就是除了少了记录表空间整体属性的部分之外，其余的部分是一样一样的。

2.4.6 IBUF_BITMAP类型

每个分组的第二个页面的类型都是IBUF_BITMAP，这种类型的页里边记录了一些有关Change Buffer的信息。

2.4.7 INODE类型

再次对比前边介绍表空间的图，第一个分组的第三个页面的类型是INODE。我们前边说过InnoDB为每个索引定义了两个段，而且为某些特殊功能定义了些特殊的段。为了方便管理，他们又为每个段设计了一个INODE Entry结构，这个结构中记录了关于这个段的相关属性。而我们这会儿要介绍的这个INODE类型的页就是为了存储INODE Entry结构而存在的。

一个INODE类型的页面是由这几部分构成的：

除了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类型的页面，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结构放入该页面

2.4.8 Segment Header结构的运用

我们知道一个索引会产生两个段，分别是叶子节点段和非叶子节点段，而每个段都会对应一个INODE Entry结构，那我们怎么知道某个段对应哪个INODE Entry结构呢？所以得找个地方记下来这个对应关系。记得之前学习过的数据页MySQL之数据页结构，也就是INDEX类型的页有一个Page Header部分，所以把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结构的地址是哪个表空间的哪个页面的哪个偏移量。这样子索引和其对应的段的关系就建立起来了。不过需要注意的一点是，因为一个索引只对应两个段，所以只需要在索引的根页面中记录这两个结构即可。

2.5 真实表空间对应的文件大小

上边的这些概念已经压的快喘不过气了。不过独立表空间有那么大么？我到数据目录里看了，一个新建的表对应的.ibd文件只占用了96K，才6个页面大小，上边的说了那么多概念，那么大的空间占用，为什么只有96KB大小？

一开始表空间占用的空间自然是很小，因为表里边都没有数据。.ibd文件是自扩展的，随着表中数据的增多，表空间对应的文件也逐渐增大。