InnoDB的表格空间-Part2(各类型页面详细情况)

今天来进一步探讨更细节的几个问题
像是XDES Entry结构到底储存在表格空间的那边？
直属於表格空间的链结串列基节点储存在表格空间那边？
每个段对应的INODE Entry结构储存在表格空间那边？

为此我们需要更进一步了解前面提到的一些分组前面的固定页面

FSP_HDR类型。
我们知道这页用来登记整个表格空间的一些整体属性及本组所有区的属性。
其实XDES Entry结构就是储存在这里。
这页包含了
- 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
- Space ID(4位元组)：表格空间ID
- Not Used(4位元组)：未被使用，可忽略
- Size(4位元组)：当前表格空间拥有的页面数
- Free Limit(4位元组)：尚未被初始化的最小页号，大於或等於这个页号对应的XDES Entry结构都没有被加入FREE链结串列，也就是说一开始只分配一部分空闲区到FREE链结串列，等空闲链结串列中对应的XDES Entry结构不够的时候，再把其加入。
- 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_FRAG链结串列基节点
- List Base Node for FULL_FRAG List(16位元组)：FULL_FRAG链结串列基节点
- Next Unused Segment ID(8位元组)：当前表格空间中下一个未使用的Segment ID，这样新增段的时候就不需要历遍整个空间中所有的段来知道下一个段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链结串列的基节点，下方会再说明
第二个XDES Entry
再来XDES Entry的部分，由於一个XDES Entry结构的大小是40位元组，由於一个页面的大小有限，只能存放一定数量的XDES Entry结构，所以才把256个区画成1组，每组的第一页存放256个XDES Entry结构。

所以我们前面的问题都有了答案
像是XDES Entry结构到底储存在表格空间的那边？
直属於表格空间的链结串列基节点储存在表格空间那边？
每个段对应的INODE Entry结构储存在表格空间那边？
都是存在每组最开始的第一页
XDES类型
大家还记得其余各组最开始二页的类型是固定的，第一页是XDES页，用来登记本组256个区的属性。基本上它的内容跟FSP_HDR几乎一样，差别只在於XDES没有File Space Header(纪录表格空间的一些整体属性资讯)。
IBUF_BITMAP类型
所有组别的第二页都是IBUF_BITMAP页，用来储存关於Change Buffer的一些资料。
我们在表中插入一笔纪录，本质上是向每个索引对应的B+树插入纪录。该纪录先插入聚簇索引页面，然後再插入每个二级索引页面。这些页面在表格空间中随机分布(虽然有双向链结串列串在一起，但物理记忆体上是不连续的，所以磁碟需要重新定位)，也产生大量的随机I/O，严重影响性能。所以引入了Change Buffer结构(本质上也是表格空间中的一颗B+树，它的根节点储存在系统表格空间中)。在修改非唯一二级索引页面时，如果该页尚未被载入到记忆体中(仍在磁碟)，那麽该修改先暂时快取到Change Buffer，等其需要载入到记忆体，才将修改合并到对应页面。（以前只会快取Insert操作，所以Change Buffer以前被称为Insert Buffer[IBUF]，但现在Update跟Delete也会快取）
INODE类型
第一组的第三页是INODE，顾名思义就是为了储存INODE Entry结构而存在的，也就是说跟第一页有些类似。内容如下：
这页包含了
- File Header：档案标头(38位元组)，页的一些通用资讯
- List Node for INODE Page List：表格空间头部(12位元组)，储存上一个INODE page和下一个INODE页面指标
- INODE Entry：段描述资讯(16320位元组)，具体的INODE Entry结构
- Empty Space：尚未使用空间(6位元组)，用於页结构的填充，没什麽实际意义
- File Trailer：档案结尾(8位元组)，验证页是否完整
  我们看两个不熟悉的属性就好
  第一个INODE Entry
  我们已经知道的结构就是对应段内的零散页面的位址及附属於该段的FREE、NOT_FULL和FULL链结串列的基节点。每个INODE Entry结构占用192位元组，一个页面可以储存16320/192=85个这样的结构。
  第二个List Node for INODE Page List
  当一个表格空间段的数量超过85个就会不够，需要额外的INODE页来储存，因此为了方便管理这些INODE页，又将其串成两个链结串列。
  SEG_INODES_FULL List(16位元组)：SEG_INODES_FULL链结串列的基节点
  SEG_INODES_FULL List(16位元组)：SEG_INODES_FULL链结串列的基节点
  这前面大家都有看到，它们的基节点的位置都是固定的，从而轻松存取。而指标的部分就存在这。