在页的7个组成部分中，我们自己存储的记录会按照我们指定的行格式存储到User%20Records部分。但是在一开始生成页的时候，其实并没有User%20Records这个部分，每当我们插入一条记录，都会从Free%20Space部分，也就是尚未使用的存储空间中申请一个记录大小的空间划分到User%20Records部分，当Free%20Space部分的空间全部被User%20Records部分替代掉之后，也就意味着这个页使用完了，如果还有新的记录插入的话，就需要去申请新的页了，这个过程的图示如下：

3、页目录（Page Directroy)

页目录是页中除了User Records部分最重要的部分了，尤其在MySQL查找记录时，通过页目录的数据结构可以帮我们避免从表中全量遍历，而是将遍历范围缩小到个位数的量级，提高了查询效率。

3.1 页目录的结构

页目录的制作过程如下：

1. 将所有正常的记录（包括最大和最小记录，不包括标记为已删除的记录）划分为几个组；
2. 每个组的最后一条记录（也就是组内主键值最大的那条记录）的头信息中的n_owned属性表示该记录对应的分组内共有几条记录；
3. 将每个组的最后一条记录的地址偏移量单独提取出来按顺序存储到靠近页的尾部的地方，这个地方就是所谓的页目录。页面目录中的这些地址偏移量被称为槽（**Slot**），所以这个页面目录就是由槽组成的。槽相当于指针，指向每个分组的最后一条记录。

InnoDB对每个分组中的记录条数是有规定的：对于最小记录所在的分组只能有 1 条记录，最大记录所在的分组拥有的记录条数只能在 1~8 条之间，剩下的分组中记录的条数范围只能在是 4~8 条之间。上面页目录制作过程的第一步分组具体的过程如下：

1. 初始情况下一个数据页里只有最小记录和最大记录两条记录，它们分属于两个分组；
2. 之后每插入一条记录，都会从页目录中找到主键值比本记录的主键值大并且差值最小的槽，然后把该槽对应的记录的n_owned值加1，表示本组内又添加了一条记录，直到该组中的记录数等于8个；
3. 在一个组中的记录数等于8个后再插入一条记录时，会将组中的记录拆分成两个组，一个组中4条记录，另一个5条记录。这个过程会在页目录中新增一个槽来记录这个新增分组中最大的那条记录的偏移量。

槽和记录的示意图如下:上图中共有5个分组，16条用户记录 + 2条最小/最大记录，其中最小记录占一个分组，最大记录跟最后4条记录是一个分组，其余的3个分组里每个分组都有4条记录。页目录在左侧（其实在页的下侧，这里是方便画图将页目录放到了左侧），因为有5个分组，所以页目录里有5个槽，每个槽指向每一个分组里的最后一条行记录。每一条行记录中，蓝色区域是记录的额外信息，包括记录头信息等，橙色区域是用户的真实数据，真实数据的第一列是主键列（即值是1~16的列）。

3.2 基于页目录的查询

记录在页中按照主键值从小到大的顺序串成一个单链表，我们如果想根据主键值查找页中的某条记录该怎么操作呢？如果按照这样的办法：从Infimum记录（最小记录）开始，沿着链表一直往后找，直到找到主键值等于待查找记录主键值的记录即可。但这种遍历整个页的搜索策略，当页中记录很多，且要搜索的记录在页中靠后位置时，搜索效率会很低。因此InnoDB提出了更高效的方法，通过页目录这个数据结构来缩小遍历的范围，从而提高搜索效率。以3.1中16条用户记录的图为例，来讲解InnoDB是如何借助页目录来提高查询效率的。上图中五个槽的编号分别是0~4，初始情况下最低的槽low=0，最高的槽high=4。过程中会用到二分法查找，现在要查找主键值为6的记录：

1. 计算中间槽的位置：(0+4)/2=2，所以查看槽2对应记录的主键值为8，又因为8 > 6，所以设置high=2，low保持不变（0）；
2. 重新计算中间槽的位置：(0+2)/2=1，所以查看槽1对应的主键值为4，又因为4 < 6，所以设置low=1，high保持不变（2）；
3. 因为high - low的值为1，所以确定主键值为6的记录在槽2对应的组中。此刻我们需要找到槽2中主键值最小的那条记录，然后沿着单向链表遍历槽2中的记录。怎么定位一个组中最小的记录呢？别忘了各个槽都是挨着的，我们可以很轻易的拿到槽1对应的记录（主键值为4），该条记录的下一条记录就是槽2中主键值最小的记录，该记录的主键值为5。所以我们可以从这条主键值为5的记录出发，遍历槽2中的各条记录，直到找到主键值为6的那条记录即可。由于一个组中包含的记录条数只能是1~8条，所以遍历一个组中的记录的代价是很小的（通过页目录将遍历范围缩小到一个组，即1~8条记录的范围）。

所以在一个数据页中查找指定主键值的记录的过程分为两步：

1. 通过二分法确定该记录所在的槽，并找到该槽所在分组中主键值最小的那条记录作为遍历的起始记录；
2. 通过记录的next_record属性遍历该槽所在的组中的各个记录，直到找到目标主键值的记录。

   4、页面头部（Page Header)

   Page Header是专门针对数据页的，记录了数据页的元数据，比如本页中已经存储了多少条记录，第一条记录的地址是什么，页目录中存储了多少个槽等等，具体各字节的用途如下：

5、文件头部（File Header)

上面介绍的Page Header是专门针对数据页的，只有数据页才有，而File Header是所有类型的页都有的，记录了页的通用元数据，它描述了一些针对各种页都通用的一些信息，比方说这个页的编号是多少，它的上一个页、下一个页是哪个等，具体字段如下：

下面介绍以下File Header中比较重要的几个字段。

5.1 FIL_PAGE_SPACE_OR_CHKSUM

即页的校验和。校验和是指对一个很长的字符串，通过某种算法来计算生成一个比较短的字符串来代表这个很长的字符串，这个比较短的字符串就是校验和，常见的校验和比如MD5、Etag等。校验和的作用是在比较两个很长的字节串之前先比较这两个长字节串的校验和，如果校验和都不一样两个长字节串肯定是不同的，所以省去了直接比较两个比较长的字节串的时间损耗。

5.2 FIL_PAGE_OFFSET

即页在表空间中的页号，InnoDB可以通过页号确定表空间中唯一一个页。

5.3 FIL_PAGE_TYPE

即页的类型，在本文最开头部分介绍了InnoDB不是仅有索引页这一种类型的页，还有很多其他类型的页。

5.4 FIL_PAGE_PREV和FIL_PAGE_NEXT

InnoDB都是以页为单位存放数据的，有时候我们存放某种类型的数据占用的空间非常大（比方说一张表中可以有成千上万条记录），InnoDB不能一次性为这么多数据分配一个非常大的连续的存储空间，如果分散到多个不连续的页中存储的话需要把这些页关联起来，FIL_PAGE_PREV和FIL_PAGE_NEXT就分别代表本页的上一个和下一个页的页号。这样通过建立一个双向链表把许许多多的页就都串联起来了，而无需这些页在物理上真正连着。需要注意的是，并不是所有类型的页都有上一个和下一个页的属性，不过数据页是有这两个属性的，所以数据页其实是一个双链表，就像这样：

6、文件尾部（File Trailer)

File Trailer主要用来校验页的完整性的，试想一下这个场景：页中的数据在内存中被修改了，在修改后的某个时刻需要把页中的数据刷新到磁盘中，但是在同步了一半的时候MySQL宕机了，在这种场景下就需要校验页的完整性了（即是否发生仅同步了页的一半数据的情况）。File Trailer共8个字节，分为两个部分：（1）前4个字节代表页的校验和这个部分是和File Header中的校验和相对应的。每当一个页面在内存中修改了，在同步之前就要把它的校验和算出来，因为File Header在页面的前边，所以校验和会被首先同步到磁盘，当完全写完时，校验和也会被写到页的尾部，如果完全同步成功，则页的首部和尾部的校验和应该是一致的，否则意味着同步中间出了错。（2）后4个字节代表页面被最后修改时对应的日志序列位置（**LSN**）。