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

原文地址： 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

页的结构以下：

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

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 须要作一些元数据记录，来追踪全部页，区以及空间自己。

空间中的第一页是 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 这三个页面做为头三页。这以后，与其余页面有点区别。

• 第 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 文件，它的结构以下：

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

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