J. Cole 的 InnoDB 系列 - 3. InnoDB空间文件布局的基础

拼搏现实的明天。 2022-11-12 11:53 76阅读 0赞

> 原文地址：[blog.jcole.us/2013/01/03/…][blog.jcole.us_2013_01_03]

在数据存储模型中，通常有“**空间**”这个概念，在 MySQL 中被称为“**表空间**”，有时候在 InnoDB 中也被称为“**文件空间**”。一个空间可能由一个操作系统中的多个实际文件组成（例如 ibdata1, ibdata2 等等），实际上只是一个逻辑文件 - 多个文理文件被当做一个连接在一起的文件处理。

InnoDB 中每个**空间**都被分配了一个 32 位的无符号整型空间 ID，这个 ID 被用来在不同的地方引用指向这个空间。InnoDB 总是有一个“系统空间”，他的空间 ID 是 0。系统空间用于保存 InnoDB 的一系列元数据的记录。通过 MySQL，InnoDB 目前只支持“一个表一个文件”空间形式的额外空间，这将为每一个 MySQL 表创建 .ibd 文件。从内部来看，这个 .ibd 文件实际是一个可以容纳多个表的完整的**空间**，但是在 MySQL 的实现中，它只能包含一个表。

# 页 #

每个**空间**被切分成了**页**，一般每**页** 16 KiB（也可以通过在编译时指定 `UNIV_PAGE_SIZE` 修改，或者开启了 InnoDB 压缩）。**空间**中的**页**会被分配一个 32 位的页码，这个页码被称为**偏移**，其实这个页码就是从**空间**地址开头的**页偏移**。所以，第 0 页位于文件偏移 0 的位置，第 1 页位于文件偏移 16384 的位置，以此类推。可能这里有些人会想起来，InnoDB 的**数据大小限制是 64 TiB**，这个其实是每个**空间**的大小限制。因为页码是一个 32 位的无符号整型，并且默认的页大小是 16 KiB，这样空间最大大小是 2^32 \* 16 KiB = 64 TiB

**页**的结构如下：

![image][]

每一页都有一个 38 字节的 `FIL` 头部和一个 `FIL` 尾部（`FIL`这个名字其实就是出自 “file”的简写）。头部包含一个表示页类型的字段，这个类型决定了页的剩下部分的结构。 `FIL` 头部和 `FIL` 尾部结构如下所示：

![image][image 1]

`FIL` 头部以及尾部包含以下结构：

*  **页类型**（2 bytes）：这对于解析剩下的页数据是很重要的。很多模块以及场景下需要分配页存储，包括**文件空间管理**，**范围管理**，**事务系统**，**数据字段**，**undo log**，**blobs 数据** 还有**索引**以及**表数据**。
 *  **空间 ID**（4 bytes）
 *  **页码**（4 bytes）：当**页**被初始化的时候页码就被存入了。检查该字段保存的页码与根据文件偏移量读取到的页码是否匹配，有助于表明读取是否是正确的。并且，如果这个字段被初始化了，表明这个**页**也被初始化了
 *  **checksum**（4 bytes）和**老版 checksum**（4 bytes）
 *  **上一页**（4 bytes）与**下一页**（4 bytes）的指针：这样可以构建双向链表，并用于**索引**页来讲所有页在同一级别链接起来，从而提高索引全扫描的效率。但是有很多页面类型不使用这些字段。
 *  头部保存**最近修改对应的 LSN**（日志序列号，8 bytes），同时这个序列号的**低 32 位也保存在尾部**。
 *  **全局最大的日志序列号**（被称为 flush LSN，8 bytes），真正的序列号只保存在第 0 个空间的第 0 页，其他页这个字段的值都是 0，相当于都复用第 0 个空间的第 0 页的这个字段。这样全局发生修改的时候只用修改一个字段就行了。

# **空间**文件 #

一个**空间文件**是很多**页**（最多 2^32）的聚合链接，为了更高效的管理，**页**被聚合成很多个 1 MiB 大小的块（64 个连续页，默认页大小是 16 KiB），这个块被称为“区”（extent）。很多结构只通过引用**区**来在一个**空间**中分配**页**

InnoDB 需要做一些元数据记录，来追踪所有**页**，**区**以及**空间**本身。

![image][image 2]

**空间**中的第一页是 `FSP_HDR`(文件空间头页)。`FSP_HDR` 页包含一个 `FSP` 结构，记录像是**空间的大小**，**空闲区**、**碎片区**和**满区**的列表等数据（将来我会写一篇详细的关于空闲空间管理介绍的文章）。 一页 `FSP_HDR` 只有够保存 256 个**区**（相当于 16384 **页**，256 MiB）信息的空间，所以每 16384 页之后，都需要额外记录这些页信息的空间。`XDES` 页和 `FSP_HDR` 页的结构是相同的，只是在 `XDES` 中 `FSP` 占用的存储都是被 0 填充的。这些额外的**页**会随着空间文件的增长而自动分配。

`INODE` 页用来保存文件**段**（Segmentation，包含一组**区**以及一个只会单独分配的碎片区的数组）的列表。每个 `INDOE` 页可以保存 85 个 `INODE` 元素，每个索引需要两个 `INODE` 元素（将来我会写一篇详细的关于 INDOE 元素内容和文件**区**的文章）。

`IBUF_BITMAP` 页保存关于插入缓存的信息，不在本系列的讨论范围内。

# 系统**空间** #

**系统空间**(第 0 个空间)比较特殊，包含许多按固定页码分配的页面，以存储对 InnoDB 操作至关重要的大量信息。系统空间与任何其他空间一样，也需要 `FSP_HDR`, `IBUF_BITMAP`，`Inode` 这三个页面作为头三页。这之后，与其他页面有点区别。

![image][image 3]

*  第 3 页，`SYS` 类型：与插入缓存相关的头信息。
 *  第 4 页，`INDEX` 类型：用于插入缓冲的索引结构的根页。
 *  第 5 页，`TRX_SYS` 类型：与 InnoDB 事务系统的操作相关的信息，例如最新的事务ID、MySQL二进制日志信息和双写缓冲区范围的位置。
 *  第 6 页，`SYS` 类型：第一个回滚段页。根据需要分配其他页(或整个区段)来存储回滚段数据。
 *  第 7 页，`SYS` 类型：与数据字典相关的头信息，包含组成数据字典的索引的根页码。这些信息能够找到任何其他索引(表)，由于它们的根页码就存储在这个数据字典中。
 *  第 64 - 127 页：双写缓冲区中第一块（包含 64 页），双写缓冲区是 InnoDB 恢复机制的一个重要部分
 *  第 128 - 191 页：双写缓冲区中第二块

其他页按需分配给索引、回滚段、撤消日志（undo logs）等.

# 每个表空间文件 #

InnoDB提供了“每个表一个文件”模式，该模式将为每个 MySQL 表创建一个文件(如上所述实际上是一个**空间**)。可能叫做“每个表一个空间”更合适一些。每个表都会创建 `.ibd` 文件，它的结构如下：

![image][image 4]

忽略快速添加索引（即在运行时添加索引），在必需的3个初始页之后，空间中分配的下一个页面将是表中每个索引的根页，按**表创建中定义的索引顺序**排列。**第 3 页将是聚集索引的根**，**第 4 页将是第一个二级索引的根**，以此类推。

由于 InnoDB 的大部分元数据结构都存储在**系统空间**中，因此在“每个表一个空间”中分配的大多数页都是 `INDEX` 类型的并存储表数据。

[blog.jcole.us_2013_01_03]: https://blog.jcole.us/2013/01/03/the-basics-of-innodb-space-file-layout/
[image]: /images/20221022/e4c8dd95e27146ad8afbbecb16ff04ab.png
[image 1]: /images/20221022/339a6b2072e6451e972959bcdb4cf472.png
[image 2]: /images/20221022/71640e61a2324362a70fbd30f989c64f.png
[image 3]: /images/20221022/51e12e16176e4fd5bd66cea01c58b93e.png
[image 4]: /images/20221022/323ed48e895c49d197eaca6186d70d8e.png