了解InnoDB存储引擎的表空间
前言
本文绝大部分内容来自《MySQL是怎样运行的》
https://book.douban.com/subject/35231266/
非常推荐的一部书。
对于每个独立表空间来说，对应着文件系统中一个名为表名.ibd的实际文件。可以把表空间想象成切分为许许多多个页的池子。当我们想为某个表插入一个条记录的时候，就从池子捞出一个对应的页，然后数据写进去。
独立表空间
区（extent）的概念
对于16KB大小的页，连续的64个页构成一个区，也就是一个区默认1MB大小。不论表空间还是独立空间，都可以看成是由多个区构成的。每256个区又分为一组。
这些组的头几个页面类似，如图：
从上图可知，第一组开始的几个页和其他组的是不同的。也就是说 extent 0这个区最开始的3个页面的类型是固定的。
FSP_HDR: 这个类型的页用于登记整个表空间的一些整体属性和本组所有的区，也就是extent0 ~ extent255这256个区的属性。整个表空间只有一个FSP_HDR页。
IBUF_BITMAP: 这个类型的页面是存储本组所有的区的所有页面关于 INSERT BUFFER 的信息。
INODE: 这个类型的页面存储了许多称为 INODE 的数据结构 ^785ffd
XDES: 全称是 extent descriptor ，用来登记本组256个区的属性，也就是说对于在 extent 256 区中的该类型页面存储的就是 extent 256 ~ extent 511 这些区的属性，对于在 extent 512 区中的该 类型页面存储的就是 extent 512 ~ extent 767 这些区的属性。上边介绍的 FSP_HDR 类型的页面其实 和 XDES 类型的页面的作用类似，只不过 FSP_HDR 类型的页面还会额外存储一些表空间的属性。 ^de82f1
此处只需大致记住： 表空间被划分为许多连续的区，每个区默认由64个页组成，每256个区划分为一组，每个组开始的几个页是固定的。
段（segment）的概念
从理论上说，不引入 区 的概念只使用 页 的概念对存储引擎的运行并没啥影响，但是我 们来考虑一下下边这个场景:
我们每向表中插入一条记录，本质上就是向该表的聚簇索引以及所有二级索引代表的 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 中还有为存储一些特殊的数据而定义的段，比如回滚段，当然我们 现在并不关心别的类型的段，现在只需要知道段是一些零散的页面以及一些完整的区的集合就好了。
区的分类
表空间是由若干个区组成的，区又有以下类型： ^5702c6
- 空闲的区：现在还没用到这个区的任何页面；
- 有剩余空间的碎片区：表示碎片区还有可用的页面；
- 没有剩余空间的碎片区：表示碎片区的所有页面均被使用，无空间页面；
- 附属与某个段的区：每一个索引都可以分为叶子节点段和非叶子节点段，除此之外InnoDB还会另外定义一些 特殊作用的段，在这些段中的数据量很大时将使用区来作为基本的分配单位。
这四种类型的区也可以称为区的四种状态（state）
| 状态名 | 含义 |
|---|---|
| FREE | 空闲的区 |
| FREE_FRAG | 有空闲页的碎片段 |
| FULL_FRAG | 无空闲页的碎片段 |
| FSEG | 附属某个段的区 |
^be7ec9
处于FREE、FREE_FRAG、 FULL_FRAG状态的区，是独立的，直属于表空间。而处于FSEG的区是附属于某个段的。
为了方便管理这些区，又设计了XDES Entry的结构（全称：Extent Descriptor Entry），中文翻译过来就是区描述符的条目。为了方便记忆，X就是Extent表示区，DES是Descriptor表示描述符。
既然是区描述符，自然每一个区都有XDES Entry，这个结构记录了一些区的属性，如图：
大致由四部分组成：
- Segment ID：顾名思义就是段ID，即当前区所属的段的ID。当然，前提是当前区已经被分配给了某个段时，这个字段才有意义。
- List Node：节点链表，如果我们想定位表空间内的某一个位置的话，只需指定页号以及该位置在指定页号中的页内偏移量即可。所
以:
Pre Node Page Number 和 Pre Node Offset 的组合就是指向前一个 XDES Entry 的指针 Next Node Page Number 和 Next Node Offset 的组合就是指向后一个 XDES Entry 的指针。 ^a03cf3 - State：区的状态，也就是上面描述的四个区类型，FREE、FREE_FRAG、FULL_FRAG、FSEG
- Page State Bitmap：页状态位图。它占用了16字节，也就是128位。上面说过一个区是有64页，所以每两位表示一个页的状态。例如，第一个比特位和第二个比特位表示第一页的状态，第三个比特位和第四个比特位表示第二页的状态。这两个比特位中的第一个表示对应的页是否为空，第二个还没有用。
XDES Entry链表
到目前为止，已经提出了许多概念，区，段，碎片区，附属段的区，XDES，我是直接懵逼的，然后根本看不下去了。😩
其实做这么多事，其目的就是在于提高插入的效率又不至于在数据量少时浪费空间。
现在我们知道向表中插入数据本质上就是向表中各个索引的叶子节点段、非叶子节点段插入数据，也知道了不同的区有不同的状态，再回到最初的起点，捋一捋向某个段中插入数据的过程:
- 当段中数据较少的时候，首先会查看表空间中是否有状态为 [[#^be7ec9|FREE_FRAG]] 的区，也就是找还有空闲空间的碎片 区，如果找到了，那么从该区中取一些零碎的页把数据插进去;否则到表空间下申请一个状态为 FREE 的 区，也就是空闲的区，把该区的状态变为 FREE_FRAG ，然后从该新申请的区中取一些零碎的页把数据插进 去。之后不同的段使用零碎页的时候都会从该区中取，直到该区中没有空闲空间，然后该区的状态就变成了FULL_FRAG 。
现在的问题是你怎么知道表空间里的哪些区是 [[#^be7ec9|FREE]] 的，哪些区的状态是 FREE_FRAG 的，哪些区是 [[#^be7ec9|FULL_FRAG]] 的?要知道表空间的大小是可以不断增大的，当增长到GB级别的时候，区的数量也就上千了， 我们总不能每次都遍历这些区对应的 [[#^de82f1|XDES Entry]] 结构吧?这时候就是 XDES Entry 中的 [[#^a03cf3|List Node]] 部分发
挥奇效的时候了，我们可以通过 List Node 中的指针，做这么三件事:
1. 把状态为 FREE 的区对应的 XDES Entry 结构通过 List Node 来连接成一个链表，这个链表我们就称之 为 FREE 链表。
2. 把状态为 FREE_FRAG 的区对应的 XDES Entry 结构通过 List Node 来连接成一个链表，这个链表我们就 称之为 FREE_FRAG 链表。
3. 把状态为 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 结构会被加入到这个链表。 ^f5a736
- 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的事情。
段的结构
^4f4c57
我们前边说过，段其实不对应表空间中某一个连续的物理区域，而是一个逻辑上的概念，由若干个零散的页面以 及一些完整的区组成。像每个区都有对应的 XDES Entry 来记录这个区中的属性一样，设计 InnoDB 的大叔为每个 段都定义了一个 INODE Entry 结构来记录一下段中的属性。大家看一下示意图:
- Segement ID
就是指这个 INODE Entry 结构对应的段的编号(ID)。 - NOT_FULL_N_USED
这个字段指的是在 [[#^f5a736|NOT_FULL]] 链表中已经使用了多少个页面。下次从 NOT_FULL 链表分配空闲页面时可以直接 根据这个字段的值定位到。而不用从链表中的第一个页面开始遍历着寻找空闲页面。
解释：NOT_FULL 说的未满的区构成的链表，一个区呢，是64页，当前这个区63页都已经满了，即第64页空的。当新数据插入时，应该插入到第64页。此时呢，我们需要从这个区的第一页开始遍历，不断判断页是否为空。所以呢，这就很耗时，
NOT_FULL_N_USED相当于提前记录了64，当下一次新插入时，直接就可以找到这个空页面了，而不需要去遍历。
- 三个LIst Base Node
对应FREE、NOT_FREE、FULL链表的基节点。这样我们要查找某个段的某个链表的头节点和尾节点时，就可以通过INODE的这部分快速查找。 - Magic Number
这个值是用来标记这个 INODE Entry 是否已经被初始化了(初始化的意思就是把各个字段的值都填进去了) - Fragment Array Entry
我们前边强调过无数次段是一些零散页面和一些完整的区的集合，每个 Fragment Array Entry 结构都对应着一个零散的页面，这个结构一共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 Space Header
- Space ID：表空间ID
- Not Used：这4个字节未被使用，可以忽略
- SIZE：当前表空间占有的页面数
- FREE Limit：尚未被初始化的最小页号，大于或等于这个页号的区对应的XDES Entry结构都没有被加入FREE链表
- Space Flags：表空间对于一些布尔类型的属性，或者只需要寥寥几个比特位搞定的属性都放在了这个 Space Flags 中存储，虽然它只有4个字节，32个比特位大小，却存储了好多表空间的属性，详细情况如下表:
| 标志名称 | 占用的空间(单位:bit) | 描述 |
|---|---|---|
| POST_ANTELOPE | 1 | 表示文件格式是否大于 ANTELOPE |
| ZIP_SSIZE | 4 | 表示压缩页面的大小 |
| ATOMIC_BLOBS | 1 | 表示是否自动把值非常长的字段放到BLOB页里 |
| PAGE_SSIZE | 4 | 页面大小 |
| DATA_DIR | 1 | 表示表空间是否是从默认的数据目录中获取的 |
| SHARED | 1 | 是否为共享表空间 |
| TEMPORARY | 1 | 是否为临时表空间 |
| ENCRYPTION | 1 | 表空间是否加密 |
| UNUSED | 18 | 没有使用到的比特位 |
- FRAG_U_USED：这个字段表明在 FREE_FRAG 链表中已经使用的页面数量，方便之后在链表中查找空闲的页面。
- 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啦。
- Next Unused Segment ID：表中每个索引都对应2个段，每个段都有一个唯一的ID，那当我们为某个表新创建一个索引的时候，就意味着要创建两个新的段。那怎么为这个新创建的段找一个唯一的ID呢?去遍历现在表空间中所有的段么?我们 说过，遍历是不可能遍历的，这辈子都不可能遍历，所以设计 InnoDB 的大叔们提出了这个名叫 Next Unused Segment ID 的字段，该字段表明当前表空间中最大的段ID的下一个ID，这样在创建新段的时候赋予 新段一个唯一的ID值就so easy啦，直接使用这个字段的值就好了。
- 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 结构的地址是固定的，所以我们访问这些结构就so easy啦，至于该结构的详细使 用情况我们已经唠叨的够明白了，在这就不赘述了。
XDES类型
我们说过，每一个 XDES Entry 结构对应表空间的一个区，虽然一个 XDES Entry 结构只占用40字节，但你抵不 住表空间的区的数量也多啊。在区的数量非常多时，一个单独的页可能就不够存放足够多的 XDES Entry 结构， 所以我们把表空间的区分为了若干个组，每组开头的一个页面记录着本组内所有的区对应的 XDES Entry 结构。 由于第一个组的第一个页面有些特殊，因为它也是整个表空间的第一个页面，所以除了记录本组中的所有区对应 的 XDES Entry 结构以外，还记录着表空间的一些整体属性，这个页面的类型就是我们刚刚说完的 FSP_HDR 类 型，整个表空间里只有一个这个类型的页面。除去第一个分组以外，之后的每个分组的第一个页面只需要记录本 组内所有的区对应的 XDES Entry 结构即可，不需要再记录表空间的属性了，为了和 FSP_HDR 类型做区别，我们 把之后每个分组的第一个页面的类型定义为 XDES ，它的结构和 FSP_HDR 类型是非常相似的:
IBUF_BITMAP类型
对比前边介绍表空间的图，每个分组的第二个页面的类型都是 IBUF_BITMAP ，这种类型的页里边记录了一些有 关 Change Buffer 的东东，由于这个 Change Buffer 里又包含了贼多的概念，考虑到大家在一章中接受这么多新 概念有点呼吸不适，怕大家心脏病犯了所以就把 Change Buffer 的相关知识放到后边的章节中，大家稍安勿躁哈。
INODE类型
再回顾一下什么是INODE及作用，INODE Entry就是用于描述[[#段的结构]]。
再次对比前边介绍的[[#^5702c6|表空间]]，第一个分组的第三个页就是INODE类型。为了方便管理，他们为每个段设计了[[#段的结构|INODE ENtry]]，这个结构记录这个段的相关属性。
现在我们介绍的INODE页，就是为了存储这些INODE Entry结构而存在的。
你想啊，一个表空间内不止一个段吧，肯定有很多段，一个段对应一个INODE Entry，则用INODE Entry。为了方便管理这些INODE Entry，就引入INODE页来存储。
从图中可以看出，一个 INODE 类型的页面是由这几部分构成的:
| 名称 | 中文名 | 占用空间大小 | 描述 |
|---|---|---|---|
| File Header | 文件头 | 38字节 | 记录页的一些通用信息 |
| List Node for INODE Page List | 通用链表节点 | 12字节 | 存储上一个INODE页面和下一个INODE页面的指针 |
| INODE Entry | INODE条目 | 16128字节 | 段的描述信息 |
| 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部分
通过它可以找到上一个INODE页与下一个INODE页，也就是说INODE页不止一个。
因为一个表空间中的INODE Entry数量可能超过85个段，所以一个INODE页存储不下，则需要额外的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 结构呢? 所以得找个地方记下来这个对应关系。
- [[Innodb数据页结构#^ca83bd|PAGE_BTR_SEG_LEAF]]
存储叶子节点段的头部信息，仅在根节点定义。 - [[Innodb数据页结构#^ca83bd|PAGE_BTR_SEG_TOP]]
存储非叶子节点段的头部信息，仅在根节点定义。
其中的 PAGE_BTR_SEG_LEAF 和 PAGE_BTR_SEG_TOP 都占用10个字节，它们其实对应一个叫 Segment Header 的结 构，该结构图示如下:
具体含义如下：
- Space ID of INODE Entry
INODE Entry所在的表空间ID - Page Number of the INODE Entry
INODE Entry结构所在INODE页面的编号 - Byte Offset of the INODE ENtry
INODE Entry结构在该页面中的偏移量
显而易见，通过Space ID可查到表空间，通过Page Number找到的哪一个INODE页，再通过Byte Offset找到具体的INODE Entry。
PAGE_BTR_SEG_LEAF 记录着叶子节点段对应的 INODE Entry 结构的地址是哪个表空间的哪个页面的哪个偏移量， PAGE_BTR_SEG_TOP 记录着非叶子节点段对应的 INODE Entry 结构的地址是哪个表空间的哪 个页面的哪个偏移量。这样子索引和其对应的段的关系就建立起来了。不过需要注意的一点是，因为一个索引只 对应两个段，所以只需要在索引的根页面中记录这两个结构即可。
真实表空间对应的大小
等会儿等会儿，上边的这些概念已经压的快喘不过气了。不过独立表空间有那么大么?我到数据目录里看了，一
个新建的表对应的 .ibd 文件只占用了96K，才6个页面大小，上边的内容该不是扯犊子吧? 哈，一开始表空间占用的空间自然是很小，因为表里边都没有数据嘛!不过别忘了这些 .ibd 文件是自扩展的，
随着表中数据的增多，表空间对应的文件也逐渐增大。
系统表空间
了解完了独立表空间的基本结构，系统表空间的结构也就好理解多了，系统表空间的结构和独立表空间基本类 似，只不过由于整个MySQL进程只有一个系统表空间，在系统表空间中会额外记录一些有关整个系统信息的页 面，所以会比独立表空间多出一些记录这些信息的页面。因为这个系统表空间最牛逼，相当于是表空间之首，所 以它的 表空间 ID (Space ID)是 0 。
系统表空间与独立表空间的一个非常明显的不同之处就是在表空间开头有许多记录整个系统属性的页面，如图:
可以看到，系统表空间和独立表空间的前三个页面(页号分别为 0 、 1 、 2 ，类型分别是 FSP_HDR 、 IBUF_BITMAP 、 INODE )的类型是一致的，只是页号为 3 ~ 7 的页面是系统表空间特有的，我们来看一下这些
多出来的页面都是干啥使的:
| 页号 | 页面类型 | 描述 |
|---|---|---|
| 3 | SYS | 存储Insert Buffer的头部信息 |
| 4 | INDEX | 存储Insert Buffer的根页面 |
| 5 | TRX_SYS | 事务系统的相关信息 |
| 6 | SYS | 第一个回滚段的页面 |
| 7 | SYS | 数据字典头部信息 |
除了这几个记录系统属性的页面之外，系统表空间的 extent 1 和 extent 2 这两个区，也就是页号从 64 ~ 191 这128个页面被称为 Doublewrite buffer ，也就是双写缓冲区。不过上述的大部分知识都涉及到了事务和多版本 控制的问题，这些问题我们会放在后边的章节集中唠叨，现在讲述太影响用户体验，所以现在我们只唠叨一下有 关InnoDB数据字典的知识，其余的概念在后边再看。
InnoDB数据字典
我们平时使用 INSERT 语句向表中插入的那些记录称之为用户数据，MySQL只是作为一个软件来为我们来保管这 些数据，提供方便的增删改查接口而已。但是每当我们向一个表中插入一条记录的时候，MySQL先要校验一下插 入语句对应的表存不存在，插入的列和表中的列是否符合，如果语法没有问题的话，还需要知道该表的聚簇索引 和所有二级索引对应的根页面是哪个表空间的哪个页面，然后把记录插入对应索引的 B+ 树中。所以说，MySQL 除了保存着我们插入的用户数据之外，还需要保存许多额外的信息，比方说:
- 某个表属于哪个表空间，表里边有多少列
- 表对应的每一个列的类型是什么
- 该表有多少索引，每个索引对应哪几个字段，该索引对应的根页面在哪个表空间的哪个页面 该表有哪些外键，外键对应哪个表的哪些列
- 某个表空间对应文件系统上文件路径是什么
- …
上述这些数据并不是我们使用 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
SYS_TABLES的列
| 列 | 描述 |
|---|---|
| NAME | 表的名称 |
| ID | InnoDB存储引擎中每个表都有一个唯一的ID |
| N_COLS | 该表拥有列的个数 |
| TYPE | 表的类型，记录了一些文件格式、行格式、压缩等信息 |
| MIX_ID | 已过时，忽略 |
| MIX_LEN | 表的一些额外的属性 |
| CLUSTER_ID | 未使用，忽略 |
| SPACE | 该表所属表空间的ID |
这个 SYS_TABLES 表有两个索引:
- 以 NAME 列为主键的聚簇索引
- 以 ID 列建立的二级索引
SYS_COLUMNS
SYS_COLUMNS的列
| 列 | 描述 |
|---|---|
| TABLE_ID | 该列所属表对应的ID |
| POS | 该列在表中是第几列 |
| NAME | 该列的名称 |
| MTYPE | main data type，主数据类型，就是那堆INT、CHAR、VARCHAR、FLOAT、DOUBLE之类的东东 |
| PRTYPE | precise type，精确数据类型，就是修饰主数据类型的那堆东东，比如是否允许NULL值，是否允许负数啥的 |
| LEN | 该列最多占用存储空间的字节数, 例如 VARCHAR(100) |
| PREC | 该列的精度，不过这列貌似都没有使用，默认值都是0 |
这个 SYS_COLUMNS 表只有一个聚集索引:
- 以 (TABLE_ID, POS) 列为主键的聚簇索引
SYS_INDEXES
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
SYS_FIELDS
SYS_FIELDS的列
| 列 | 描述 |
|---|---|
| INDEX_ID | 该索引列所属的索引的ID |
| POS | 该索引列在某个索引中是第几列 |
| COL_NAME | 该索引列的名称 |
这个SYS_FIELDS表只有一个聚簇索引：
- 以(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存储引擎的一些全局属性，说话太啰嗦，直接看这个页面的示意图:
可以看到这个页面由下边几个部分组成:
| 名称 | 中文名 | 占用空间大小 | 描述 |
|---|---|---|---|
| File Header | 文件头 | 38字节 | 记录页面的通用信息 |
| Data Dictionary Header | 数据字典头 | 56字节 | 记录一些基本系统表的根页面位置以及InnoDB存储引擎的一些全局信息 |
| Empty Space | 未使用 | 16272字节 | 用于页结构的填充，没啥实际意义 |
| Segment Header | 段头部信息 | 10字节 | 记录本页面所在段对应的INODE Entry位置信息 |
| 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个字节没用，跳过。
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 开头的表中的字段并不完全一样，但供大家参考已经足矣
总结图
- 0
- 0
-
分享