Xdes&Inode&Seg Header(6) 独立表空间结构（三十二)

前面说了每256个区为一组，而FSP HDR是第一个组extent0 里面第一个页，这里面有特殊的file space Header部分，整个表空间直属管理，存着free链表，free_frag链表，full_frag链表，及其fseg里面的free，not full，full链表的基点，方便以后定位。

因为在磁盘中操作是非常耗性能的，所以不可能每次创建一个表，都去申请空间存放，于是就有了free_limit的，一次性申请很大的空间，这个字段之前的是未被初始化，之后的是已经初始化并且使用的。

及其xdes部分，每个组都有256个区，每个区都有一个对应的xdes entry结构，这256个entry都存在第一个页中。

File Space Header & xdes(5)FSP HDR独立表空间结构（三十一)

XDES类型

虽然一个xdes enrty只有40个字节，但架不住数量多，所以把256个区分为一个组，每个组的第一个页面存放xdes entry，以后每个区都有这个xdes类型，不同的是extent0里面叫fsp hdr，而fsp 整个表空间唯一一个页面，并且里面有file space header部分，以后的页面里只有xdes类型。

IBUF_BITMAP类型

每个分组的第二页都是IBUF_BITMAP类型，这里面记录着change buffer的东西，之后会详细介绍这里。

INODE类型

我们回忆一下，FSP HDR属于第一个extent0.这里面还有一个特殊的inode类型页，这个就是为了管理端的inode entry，他由几个部分组成：

1. file header：38个字节，页的通用信息。
2. List node for inode page list:12个字节，存储当前页的位子，和上下页的偏移。
3. INODE Entry:段的描述，存储着inode entry0，inode entry1等等。
4. Empty space:6个节点，尚未使用的空间，用于页结构的填充。
5. File Trailer:文件尾部，效验页是否完整。

我们重点关注list node for inode page list，inode entry。

Inode entry之前都介绍过，里面有segment id，和三个链表，free，not full，full链表，每个inode entry有192个字节，一个页可以存储85个这样的结构。

List node for inode page list:因为表空间有超过85个段，inode 类型页不足以存储那么多数据，所以mysql将inode类型串联成两个不同的链表：

1. seg_inode_full链表：该链表里的inode类型页已经没有空闲空间来存储inode entry。
2. seg_inode_free链表：该链表里的inode类型页还可以存放inode entry。

这里是不是很熟悉，他们两个的基节点都在file space header里面，所以查找这两个链表的时候很容易找到，当找到就先看seg_inode_free链表是否有空闲的空间，有的话直接放入数据，如果没有，则吧seg_inode_free的数据存入

Seg_inode_full里面。

当链表为null的时候，就从free_frag里申请一个页面，修改该页面类型为inode，吧这个放入seg_inode_free里面，同事吧inode entry放入该页面。

Segment header 结构运用

我们知道一个索引会有一个叶子节点和非叶子节点，所以就是有两个段，那我们怎么知道某个段对应那个inode entry呢，所以我们在这个segment header里记录下关系。我们之前记录的数据页里有一个page header，里面有

Page_btr_seg_leaf：10个字节，b+树叶子段的头部信息，仅在根页定义。

Page_btr_seg_top：10个字节，b+树非叶子段的头部信息，仅在根页定义。

他们都有一个对应的segment header结构：

1. space id of inode entry：对应inode entry所在的表空间。
2. page number of inode entry：对应的inode entry 所在的页面号。
3. byte offset of inode entry：对应inode entry偏移量。

他们一个记录着叶子段的信息，一个记录着非叶子段的信息。不过需要注意的是，因为一个索引只对应两个段，所以只需要索引的根目录记录着这两个结构就好。