InnoDB的表空间

表空间是⼀个抽象的概念，对于系统表空间来说，对应着⽂件系统中⼀个或多个实际⽂件；对于每个独⽴表空间来说，对应着⽂件系 统中⼀个名为表名.ibd的实际⽂件。⼤家可以把表空间想象成被切分为许许多多个⻚的池⼦，当我们想为某个表插⼊⼀条记录的时候，就从池⼦中捞出⼀个对应的 ⻚来把数据写进去。

表空间是一个抽象的概念，对应文件系统中的文件，后缀为.ibd的文件就是表空间。除了.ibd文件，还有后缀为.frm的文件，用来描述表空间结构的文件。

页多种多样，在InnoDB中我们接触最多的就是索引页

 ⻚⾯通⽤部分

我们前边说过数据⻚，也就是INDEX类型的⻚由7个部分组成，其中的两个部分是所有类型的⻚⾯都通⽤的。当然我不能寄希望于你把我说的话都记住，所以在这 ⾥重新强调⼀遍，任何类型的⻚⾯都有下边这种通⽤的结构：

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

File Header：记录⻚⾯的⼀些通⽤信息

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

File Header的各个组成部分（记录⻚⾯的⼀些通⽤信息）：

表空间中的每⼀个⻚都对应着⼀个⻚号，也就是FIL_PAGE_OFFSET，这个⻚号由4个字节组成，也就是32个⽐特位，所以⼀个表空间最多可以拥有2³²个⻚，如 果按照⻚的默认⼤⼩16KB来算，⼀个表空间最多⽀持64TB的数据。表空间的第⼀个⻚的⻚号为0，之后的⻚号分别是1，2，3...依此类推

某些类型的⻚可以组成链表，链表中的⻚可以不按照物理顺序存储，⽽是根据FIL_PAGE_PREV和FIL_PAGE_NEXT来存储上⼀个⻚和下⼀个⻚的⻚号。需要注意 的是，这两个字段主要是为了INDEX类型的⻚，也就是我们之前⼀直说的数据⻚建⽴B+树后，为每层节点建⽴双向链表⽤的，⼀般类型的⻚是不使⽤这两个字 段的。

每个⻚的类型由FIL_PAGE_TYPE表示，⽐如像数据⻚的该字段的值就是0x45BF，我们后边会介绍各种不同类型的⻚，不同类型的⻚在该字段上的值是不同的 

独立表空间结构

区（extent）的概念

表空间中的⻚实在是太多了，为了更好的管理这些⻚⾯，提出了区（英⽂名：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的信息。当然，你现在不⽤知道啥是个INSERT BUFFER，后边会 详细说到你吐。

INODE类型：这个类型的⻚⾯存储了许多称为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个区划分为⼀ 组，每个组的最开始的⼏个⻚⾯类型是固定的就好了。

段（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中还 有为存储⼀些特殊的数据⽽定义的段，⽐如回滚段，当然我们现在并不关⼼别的类型的段，现在只需要知道段是⼀些零散的⻚⾯以及⼀些完整的区的集合就好 了。 区的分类 通过上边⼀通唠叨，⼤家知道了表空间的是由若⼲个区组成的，这些区⼤体上可以分为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的结构：

如果我们想定位表空间内的某⼀个位置的话，只需指定⻚号以及该位置在指定⻚号中的⻚内偏移量即可。所以： 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 State Bitmap部分的第1和第2个⽐特位对应着区中的第1个⻚⾯，第3和第4个⽐特位对应着区中的第2个⻚⾯，依此类推，Page State Bitmap部分的第127和128个⽐特位对应着区中的第64个⻚⾯。这两个⽐特位的第⼀个位表示对应的⻚是否是空闲的，第⼆个⽐特位还没有⽤。 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 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 Base Node的结构，翻译成中⽂就是链表的基节点。这个结构中包含了链表的头节点和尾节点的指针以及这个链表中包含了多少节 点的信息，我们画图看⼀下这个结构的示意图： 

我们上边介绍的每个链表都对应这么⼀个List Base Node结构，其中： List Length表明该链表⼀共有多少节点， First Node Page Number和First Node Offset表明该链表的头节点在表空间中的位置。 Last Node Page Number和Last Node Offset表明该链表的尾节点在表空间中的位置。 ⼀般我们把某个链表对应的List Base Node结构放置在表空间中固定的位置，这样想找定位某个链表就变得so easy啦。 链表⼩结 综上所述，表空间是由若⼲个区组成的，每个区都对应⼀个XDES Entry的结构，直属于表空间的区对应的XDES Entry结构可以分成FREE、FREE_FRAG和 FULL_FRAG这3个链表；每个段可以附属若⼲个区，每个段中的区对应的XDES Entry结构可以分成FREE、NOT_FULL和FULL这3个链表。每个链表都对应⼀个List Base Node的结构，这个结构⾥记录了链表的头、尾节点的位置以及该链表中包含的节点数。正是因为这些链表的存在，管理这些区才变成了⼀件so easy的事 情。 段的结构 我们前边说过，段其实不对应表空间中某⼀个连续的物理区域，⽽是⼀个逻辑上的概念，由若⼲个零散的⻚⾯以及⼀些完整的区组成。像每个区都有对应的XDES Entry来记录这个区中的属性⼀样，设计InnoDB的⼤叔为每个段都定义了⼀个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。so easy! Magic Number： 这个值是⽤来标记这个INODE Entry是否已经被初始化了（初始化的意思就是把各个字段的值都填进去了）。如果这个数字是值的97937874，表明该INODE Entry已经初始化，否则没有被初始化。（不⽤纠结这个值有啥特殊含义，⼈家规定的）。 Fragment Array Entry 我们前边强调过⽆数次段是⼀些零散⻚⾯和⼀些完整的区的集合，每个Fragment Array Entry结构都对应着⼀个零散的⻚⾯，这个结构⼀共4个字节，表示 ⼀个零散⻚⾯的⻚号。 结合着这个INODE Entry结构，⼤家可能对段是⼀些零散⻚⾯和⼀些完整的区的集合的理解再次深刻⼀些。 各类型⻚⾯详细情况 到现在为⽌我们已经⼤概清楚了表空间、段、区、XDES Entry、INODE Entry、各种以XDES Enty为节点的链表的基本概念了，可是总有⼀种⻜在天上不踏实的感 觉，每个区对应的XDES Entry结构到底存储在表空间的什么地⽅？直属于表空间的FREE、FREE_FRAG、FULL_FRAG链表的基节点到底存储在表空间的什么地⽅？每 个段对应的INODE Entry结构到底存在表空间的什么地⽅？我们前边介绍了每256个连续的区算是⼀个组，想解决刚才提出来的这些个疑问还得从每个组开头的⼀ 些类型相同的⻚⾯说起，接下来我们⼀个⻚⾯⼀个⻚⾯的分析，真相⻢上就要浮出⽔⾯了。 FSP_HDR类型 ⾸先看第⼀个组的第⼀个⻚⾯，当然也是表空间的第⼀个⻚⾯，⻚号为0。这个⻚⾯的类型是FSP_HDR，它存储了表空间的⼀些整体属性以及第⼀个组内256个区 的对应的XDES Entry结构，直接看这个类型的⻚⾯的示意图：

从图中可以看出，⼀个完整的FSP_HDR类型的⻚⾯⼤致由5个部分组成，各个部分的具体释义如下表 

 

 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部分。所以之后定位这⼏个链表就so easy啦。 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个⽐特位⼤⼩，却存储 了好多表空间的属性，详细情况如下表：

 

 

 除了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结构放⼊该⻚⾯。 Segment Header 结构的运⽤ 我们知道⼀个索引会产⽣两个段，分别是叶⼦节点段和⾮叶⼦节点段，⽽每个段都会对应⼀个INODE Entry结构，那我们怎么知道某个段对应哪个INODE Entry结 构呢？所以得找个地⽅记下来这个对应关系。希望你还记得我们在唠叨数据⻚，也就是INDEX类型的⻚时有⼀个Page Header部分，当然我不能指望你记住，所以 把Page Header部分再抄⼀遍给你看：

系统表空间

 可以看到，系统表空间和独⽴表空间的前三个⻚⾯（⻚号分别为0、1、2，类型分别是FSP_HDR、IBUF_BITMAP、INODE）的类型是⼀致的，只是⻚号为3～7的⻚⾯ 是系统表空间特有的，我们来看⼀下这些多出来的⻚⾯都是⼲啥使的

除了这⼏个记录系统属性的⻚⾯之外，系统表空间的extent 1和extent 2这两个区，也就是⻚号从64~191这128个⻚⾯被称为Doublewrite buffer，也就是双写 缓冲区。不过上述的⼤部分知识都涉及到了事务和多版本控制的问题，这些问题我们会放在后边的章节集中唠叨，现在讲述太影响⽤户体验，所以现在我们只唠 叨⼀下有关InnoDB数据字典的知识，其余的概念在后边再看。 InnoDB数据字典 我们平时使⽤INSERT语句向表中插⼊的那些记录称之为⽤户数据，MySQL只是作为⼀个软件来为我们来保管这些数据，提供⽅便的增删改查接⼝⽽已。但是每当 我们向⼀个表中插⼊⼀条记录的时候，MySQL先要校验⼀下插⼊语句对应的表存不存在，插⼊的列和表中的列是否符合，如果语法没有问题的话，还需要知道该 表的聚簇索引和所有⼆级索引对应的根⻚⾯是哪个表空间的哪个⻚⾯，然后把记录插⼊对应索引的B+树中。所以说，MySQL除了保存着我们插⼊的⽤户数据之 外，还需要保存许多额外的信息，⽐⽅说： 某个表属于哪个表空间，表⾥边有多少列 表对应的每⼀个列的类型是什么 该表有多少索引，每个索引对应哪⼏个字段，该索引对应的根⻚⾯在哪个表空间的哪个⻚⾯ 该表有哪些外键，外键对应哪个表的哪些列 某个表空间对应⽂件系统上⽂件路径是什么 balabala ... 还有好多，不⼀⼀列举了 上述这些数据并不是我们使⽤INSERT语句插⼊的⽤户数据，实际上是为了更好的管理我们这些⽤户数据⽽不得已引⼊的⼀些额外数据，这些数据也称为元数据。 InnoDB存储引擎特意定义了⼀些列的内部系统表（internal system table）来记录这些这些元数据：

 这些系统表也被称为数据字典，它们都是以B+树的形式保存在系统表空间的某些⻚⾯中，其中SYS_TABLES、SYS_COLUMNS、SYS_INDEXES、SYS_FIELDS这四个表尤 其重要，称之为基本系统表（basic system tables），我们先看看这4个表的结构：

 这个SYS_TABLES表有两个索引： 以NAME列为主键的聚簇索引 以ID列建⽴的⼆级索引

 这个SYS_COLUMNS表只有⼀个聚集索引： 以(TABLE_ID, POS)列为主键的聚簇索引

 这个SYS_INEXES表只有⼀个聚集索引： 以(TABLE_ID, ID)列为主键的聚簇索引

 这个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 Dictionary Header，也就是数据字典的头部信息。除了这4个表的5个索引的根⻚⾯信息外，这个⻚号为7的⻚⾯还记录了整个InnoDB存储引擎的⼀些全局属 性，说话太啰嗦，直接看这个⻚⾯的示意图

 

 information_schema系统数据库 需要注意⼀点的是，⽤户是不能直接访问InnoDB的这些内部系统表的，除⾮你直接去解析系统表空间对应⽂件系统上的⽂件。不过设计InnoDB的⼤叔考虑到查看 这些表的内容可能有助于⼤家分析问题，所以在系统数据库information_schema中提供了⼀些以innodb_sys开头的表：

information_schema系统数据库 需要注意⼀点的是，⽤户是不能直接访问InnoDB的这些内部系统表的，除⾮你直接去解析系统表空间对应⽂件系统上的⽂件。不过设计InnoDB的⼤叔考虑到查看 这些表的内容可能有助于⼤家分析问题，所以在系统数据库information_schema中提供了⼀些以innodb_sys开头的表：