InnoDB 是一个将表中的数据存储到磁盘上的存储引擎，所以即使重启我们的数据还是存在的。而真正处理数据的过程是发生在内存中的，所以需要把磁盘中的数据加载到内存中，如果是处理写入或修改请求的话，还需要把内存中的内容刷新到磁盘上。由于读写磁盘的速度非常慢，InnoDB 将数据划分为若干个页，以页作为磁盘和内存之间交互的基本单位。

页是 InnoDB 管理存储空间的基本单位，一个页的大小一般是 16KB。也就是在一般情况下，一次最少从磁盘中读取 16KB 的内容到内存中，一次最少把内存中的 16KB 内容刷新到磁盘。InnoDB 为了不同的目的而设计了许多种不同类型的页，比如存放表空间头部信息的页，存放 Insert Buffer 信息的页，存放 undo 日志信息的页等。当然我们聚焦的是那些存放我们表中记录的那种类型的页，官方称这种存放记录的页为索引（INDEX）页，我们也称之为数据页。

数据页结构

数据页代表的这块 16KB 大小的存储空间被划分为了多个部分，不同部分有不同的功能，具体如下图所示：

• File Header：文件头部，用来存储页的一些通用信息
• Page Header：页面头部，存储数据页专有的一些信息
• Infimum+supremum：最小记录和最大记录，两个虚拟的行记录
• User Records：用户记录，实际存储的行记录内容
• Free Space：空闲空间，页中尚未使用的空间
• Page Directory：页目录，页中某些记录的相对位置，便于二分查找指定记录
• File Tailer：文件尾部，校验页是否完整

1. File Header

File Header 针对各种类型的页都通用，不止有数据页，其他不同类型的页都会以 File Header 作为第一个组成部分，它描述了一些针对各种页都通用的一些信息，比方说这个页的编号是多少，它的上一个页、下一个页的信息等等，这个部分占用固定的 38 个字节，具体各个字节的含义如下：

InnoDB 是以页为单位存放数据的，有时候我们存放某种类型的数据占用的空间非常大，InnoDB 可能不可以一次性为这么多数据分配一个非常大的存储空间，如果分散到多个不连续的页中存储的话则需要把这些页关联起来， FIL_PAGE_PREV 和 FIL_PAGE_NEXT 就分别代表本页的上一个和下一个页的页号。这样通过建立一个双向链表把许许多多的页就都串联起来了，而无需这些页在物理上真正连续。

需要注意的是，并不是所有类型的页都有上一个和下一个页的属性，不过，数据页是有这两个属性的，所以所有的数据页其实是一个双链表的结构，就像这样：

2. Page Header

InnoDB 存储引擎为了能直接得到一个数据页中存储的记录的状态信息，比如本页中已经存储了多少条记录，第 一条记录的地址是什么，页目录中存储了多少个槽等等，特意在数据页中定义了一个叫 Page Header 的部分， 这部分占用固定的 56 个字节，专门存储各种状态信息，具体各个字节的含义如下：

3. 行记录

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

对于每条行记录，也有其特定的格式，InnoDB 存储引擎默认使用的行格式为 Compact，格式具体如下：

1.1 行记录隐藏列

在记录的真实数据中，除了我们自己定义的列的数据以外，MySQL 会为每个行记录默认添加一些隐藏列：

这里需要提一下 InnoDB 表对主键的生成策略：优先使用用户自定义主键作为主键，如果用户没有定义主键，则选取一个唯一索引键作为主键，如果没有定义唯一索引键，则 InnoDB 会为表默认添加一个名为 row_id 的隐藏列作为主键。所以我们从上表中可以看出：InnoDB 存储引擎会为每条记录都添加 transaction_id 和 roll_pointer 这两个列，但是 row_id 是可选的。

1.2 行记录头信息

下面，我们重点关注记录头信息，该部分由固定 5 个字节组成，即 40 个二进制位，分别有不同的含义。这些位代表的含义比较重要，下面我们来详细分析下：

delete_mask
这个属性标记着当前记录是否被删除，占用 1 个二进制位，值为 0 时表示记录没有被删除，值为 1 时表示记录被删除掉了。被删除的记录之所以不立即从磁盘上移除，是因为移除它们之后把其他的记录在磁盘上重新排列需要性能消耗，所以只是打一个删除标记，所有被删除掉的记录都会组成一个所谓的垃圾链表，在这个链表中的记录占用的空间称之为可重用空间，之后如果有新记录插入到表中的话，可能把这些被删除的记录占用的存储空间覆盖掉。

min_rec_mask
B+ 树的每层非叶子节点中的最小记录都会添加该标记，占用 1 个二进制位。

n_owned
表示当前记录组内拥有的记录数，占用 4 个二进制位。

heap_no
这个属性表示当前记录在本页中的位置，占用 13 个二进制位。这个位置是从 2 开始的，比如我们向一个新表中插入四条记录，则这四条记录在页中的位置分别是：2、3、4、5。那 heap_no 值为 0 和 1 的记录呢？其实是 InnoDB 会自动给每个页里加两个记录，由于这两个记录并不是我们自己插入的，所以也称为伪记录。这两个伪记录一个代表最小记录，一个代表最大记录（比较记录的大小就是比较主键的大小）。

不管我们向页中插入了多少自己的数据，InnoDB 定义的这两条伪记录都代表着最小记录与最大记录。并且，由于这两条记录不是我们自己定义的记录，所以它们也并不存放在页的 User Records 部分，他们会被单独放在一个称为 Infimum + Supremum 的部分。

record_type
这个属性表示当前记录的类型，占用 3 个二进制位。一共有四种类型的记录：0 表示普通记录、1 表示 B+ 树非叶子节点记录、2 表示最小记录、3 表示最大记录。从上图中我们可以看到，我们自己插入的记录就是普通记录，它们的 record_type 值都是 0，而最小记录和最大记录的 record_type 值分别为 2 和 3 。

next_record
这个属性表示从当前记录的真实数据到下一条记录的真实数据的地址偏移量，占用 16 个二进制位。比方说第一条记录的 next_record 值为 32，意味着从第一条记录的真实数据的地址处向后找 32 个字节便是下一条记录的真实数据。这其实就是个链表，可以通过一条记录找到它的下一条记录。但要注意的是，下一条记录指得并不是按照插入顺序的下一条记录，而是按照主键值由小到大的顺序的下一条记录。而且规定 Infimum 的下一条记录就是 本页中主键值最小的用户记录，而本页中主键值最大的用户记录的下一条记录就是 Supremum。

从图中可以看到，我们的记录按照主键从小到大的顺序形成了一个单链表。最大记录的 next_record 值为 0，表示最大记录没有下一条记录了，它是这个单链表中的最后一个节点。如果我们删除第二条记录，第二条记录的 delete_mask 值会被设置为 1，并且 next_record 值会被设置为 0，第一条记录的 next_record 会直接指向第三条记录。

4. Page Directory

记录在页中按照主键值由小到大顺序串联成一个单链表，当我们想根据主键值查找页中的某条记录，可以从最小记录（Infimum）开始，沿链表一直往后找，直到找到与你想要查找的主键值相等的某个链表节点。这个方法在页中存储的记录数量较少时用起来没啥问题，但如果一个页中存储了非常多的记录，这种查找方式对性能来说还是有损耗的。于是 InnoDB 为每个页维护了一个页目录（Page Directory），页目录的制作过程如下：

• 将所有正常的记录（包括最大和最小记录，不包括标记为已删除的记录）划分为几个组。

• 每个组的最后一条记录（组内最大记录）的记录头信息中的 n_owned 属性记录了该组内有几条记录。

• 将每个组的最后一条记录的地址偏移量单独提取出来按顺序存储到页目录中，页面目录中的这些地址偏移量被称为槽（Slot），所以页目录就是由多个槽组成的。

假设，现在的 page_demo 表中正常的记录共有 6 条，InnoDB 会把它们分成两组，如下图所示：

从图中可以看到，页目录部分中有两个槽，也就意味着我们的记录被分成了两个组。注意最小和最大记录的记录头信息中的 n_owned 属性值，最小记录的 n_owned 值为 1，表示以最小记录结尾的这个分组中只有 1 条记录，也就是最小记录本身。最大记录的 n_owned 值为 5，表示以最大记录结尾的这个分组中有 5 条记录，包括最大记录本身还有我们自己插入的 4 条记录。

为什么最小记录的 n_owned 值为 1，而最大记录的 n_owned 值为 5 呢？因为 InnoDB 对每个分组中的记录条数是有规定的：对于最小记录所在的分组只能有 1 条记录，最大记录所在的分组拥有的记录条数只能在 1~8 条之间，剩下的分组中记录的条数范围只能在是 4~8 条之间。所以分组是按照下边的步骤进行的：

• 初始情况下一个数据页里只有最小记录和最大记录两条记录，它们分属于两个分组。

• 之后每插入一条记录，都会从页目录中找到主键值比本记录的主键值大并且差值最小的槽，然后把该槽对应的记录的 n_owned 值加 1，表示本组内又添加了一条记录，直到该组中的记录数等于 8 个。

• 在一个组中的记录数等于 8 个后再插入一条记录时，会将组中的记录拆分成两个组，一个组 4 条记录另一个组 5 条记录。这个过程会在页目录中新增一个槽来记录这个新增分组中最大的那条记录的偏移量。

我们向 page_demo 表中再添加一些记录，然后查看其页目录：

现在我们来看下，InnoDB 是怎么根据这个页目录来快速查找记录的。因为各个槽代表的记录的主键值都是从小到大排序的，所以我们可以使用二分法来进行快速查找。五个槽的编号分别是：0、1、2、3、4，假如我们想要找主键值为 6 的记录，查找过程是这样的：

• 计算中间槽的位置：(0+4)/2=2，所以查看槽 2 对应记录的主键值为 8，又因为 8 > 6，所以设置 high=2，low 保持不变。
• 重新计算中间槽的位置：(0+2)/2=1，所以查看槽 1 对应的主键值为 4，又因为 4 < 6，所以设置 low=1，high 保持不变。

• 因为 high - low 的值为1，所以确定主键值为 5 的记录在槽 2 对应的组中。此刻我们需要找到槽 2 中主键值最小的那条记录，然后沿着 next_record 单向链表遍历槽 2 中的记录。虽然每个槽对应的记录都是该组中主键值最大的记录，但各个槽位置是内存连续的，我们可以很轻易的拿到槽 1 对应的记录（主键值为 4），该条记录的下一条记录就是槽 2 中主键值最小的记录，该记录的主键值为 5。所以我们可以从这条主键值为 5 的记录开始遍历槽 2 中的各条记录，直到找到主键值为 6 的那条记录即可。由于一个组中包含的记录条数只能是 1~8 条，所以遍历一个组中的记录的代价是很小的。

  5. File Trailer

  我们知道 InnoDB 存储引擎会把数据存储到磁盘上，但是磁盘速度太慢，需要以页为单位把数据加载到内存中处 理，如果该页中的数据在内存中被修改了，那么在修改后的某个时间需要把数据同步到磁盘中。但如果在同步了一半的时候断电了，那么已经同步到磁盘中的这个页就不是完整的。为了检测一个页是否完整，InnoDB 在每个页的尾部都加了一个 File Trailer 部分，这个部分由 8 个字节组成，可以分成 2 个小部分：

• 前 4 个字节代表页的校验和，这个部分是和 File Header 中的校验和相对应的。每当一个页面在内存中修改了，在同步前就要把它的校验和算出来，因为 File Header 在页面的前边，所以校验和会先同步到磁盘，当完全写完时，校验和也会被写到页的尾部，如果完全同步成功，则页的首部和尾部的校验和应该是一致的。如果写了一半儿断电了，那么在 File Header 中的校验和就代表着已经修改过的页，而在 File Trialer 中的校验和代表着原先的页，二者不同则意味着同步中间出了错。这会导致 MySQL crash。

• 后 4 个字节代表页面被最后修改时对应的日志序列位置（LSN），这个部分也是为了校验页的完整性的。

这个 File Trailer 与 File Header 类似，都是所有类型的页通用的。