来源：原创投稿

作者：花家舍

简介：数据库技术爱好者。

• GreatSQL社区原创内容未经授权不得随意使用，转载请联系小编并注明来源。

简单学习一下数据文件解析

这是尝试使用Golang语言简单解析MySQL 8.0的数据文件（*.ibd）过程的一个简单介绍，解析是反序列化的一个过程，或者叫解码的过程。

1.为什么要解析

虽然有很多开源的代码已经实现了这个解码过程，例如使用C实现的undrop-for-innodb[1]，支持到MySQL 5.7版本，后续未作更新。

姜老师的py_innodb_page_info.py也可以对数据文件进行分析（分析页的类型），对MySQL 8.0版本的兼容好像还没来得及做。

还有Ali使用Java实现了数据文件的解析[2]，并且一定程度兼容MySQL 8.0版本。但是自己通过解析数据文件过程对数据文件编码/解码、恢复已删除数据等进行深入学习。

解析过程枯燥乏味，有种按图索骥的感觉，即通过文档或者源码描述的页结构，建立对应结构体来解析，难度可能并不复杂，通过对存储建立更为立体全面的认识，补齐MySQL知识拼图很有意义。

2.使用Golang解析数据文件

选择使用Golang来实现这个过程，则是因为其比C++简单的多，易上手，不用过多关注垃圾回收问题，代码简洁，有丰富的软件包以供引用，不需费力自己实现。

当然还有更多有吸引力的特性，例如并发性（goroutine）与通道（channel），对gRPC与Protocol Buffers一流的支持等，这些优秀的特性在本文解析MySQL数据文件时并没有用到，则无需赘言。

3.文件

3.1 linux文件

文件是对I/O设备的一个抽象概念，比如我们不需要了解磁盘技术就可以处理磁盘文件内容，就是通过操作文件这个抽象来进行的。

在CSAPP（ComputerSystem: A programer perspective）中文版第三版中，对文件有过精辟的定义：文件就是字节序列，仅此而已。那么对MySQL数据文件的解析，可视为对字节序列的解析，解析的过程由此可以简单地视为对编码规则的逆向过程，即解码。

3.2 MySQL 8.0数据文件

MySQL在8.0版本中对数据字典做了重新调整，元数据统一存储到InnoDB数据字典表。不再在Server层中冗余表结构信息（不再存储在ibdata中），也不再在frm文件中存储。

不仅将元数据信息存储在数据字典表中，同时也冗余了一份在SDI（Serialized Dictionary Information）中，而对于InnoDB，SDI数据则直接存储在ibd数据文件中，文件中有SDI类型页来进行存储。因为元数据信息均存储在InnoDB引擎表中，支持crash-safe，结合一套DDL_LOG机制，以此实现了DDL原子性。

在文件的开头（并不是非常靠前的位置，大概是第四个数据页，page number=3，这在之前的版本中是所谓的根页：root page）冗余表结构信息，非常类似于Avro的编码格式，即在包含几百万记录的大文件开头包含模式（描述数据的组成，包括元素组成，数据类型等）信息，后续每个记录则不再冗余这部分信息，以达到节省存储、传输成本目的。

而在解析数据时，模式是必要的，需要首先获取表结构信息，以便于后续数据解码过程。所以在这次解析数据文件时，首先需要获取数据文件中SDI页中的表结构（模式）。

为简化解析过程，默认数据库是设置了UTF-8字符集，即数据文件是以UTF-8进行编码的。并且数据库启用了innodb_file_per_table参数，表被存储在他们自己的表空间里（*.ibd）。

4.解析文件

解析并不是非常复杂的过程。就程序角度而言首先是打开文件，然后是解析文件，最后是关闭文件。

但是过程很有可能产生其他未知的问题，例如不同的编码格式，复杂的数据类型等，只是在本文解析中选择了回避而已。

Golang提供了os.OpenFile()函数来打开文件（建议以只读模式打开），并提供了file.Close()函数来关闭文件，留下了解析过程来自己实现。

4.1 获取表结构

像JSON或者XML这种自我描述的数据，其自我描述部分比较冗余，在大文件中，冗余过多信息很不明智。而在MySQL的数据文件中，数据增长是个显著问题，自我描述的部分需要精简，不能每写入一条数据，就要跟随写入表名、列名。

所以MySQL仅在文件开头保存了表结构信息（在更早的版本，表结构信息则是存储在frm文件中，并在数据字典中冗余）。

这种方式的编码可以很节省存储空间，但解析打开数据文件，输出的是字节序列，显然是人类不可读的，需要找到模式（表结构信息）来解读成人类可读，才达到解析的目的。

如果可以通过数据库，很容易获得表结构信息，但如果仅有一个数据文件，获取表结果信息只能从SDI中解析获取，过程比较麻烦。

幸运的是，MySQL官方提供了专有工具：ibd2sdi。通过ibd2sdi默认获取的是所有的列和索引信息，是以JSON格式输出的。

4.2 结构体和切片

MySQL的数据文件中是以页（默认大小为16k）为单位存储，索引可以利用B-tree的查找特性快速的定位到页，在页内的数据则是通过非常类似于二分查找的方式来定位。

在解析数据文件时，也是以页为单位，InnoDB中大概有31种类型页，在源码storage/innobase/include/fil0fil.h中可以看到相关定义。

真正存储用户数据的是FIL_PAGE_INDEX（数字编码是17855，解析到page_type=17855，代表这是一个索引页）类型的页，这不代表其他类型的页没有用处，在描述文件中页的使用的情况（FIL_PAGE_TYPE_FSP_HDR），空页分配（FIL_PAGE_TYPE_ALLOCATED），insert buffer（FIL_PAGE_IBUF_FREE_LIST），压缩页（FIL_PAGE_COMPRESSED）等，需要各种类型页进行存储不同的信息。

而不同的页，在解析过程中，则使用Golang的结构体（struct）来进行抽象表示，这类似于Java的类，是对具体事务的抽象，也非常类似于C语言的结构体。解析不同的数据页，则使用相应的结构体，为了简化解析过程（毕竟是学习过程），只对大概六种页进行了解析。

不光是页在解析过程中使用结构体，在页中的一些部分也是用了结构体来进行抽象，例如每个数据页的开头会有38个字节的File Header[3]，在解析过程中，也是通过结构体进行解析的。

第3节中说文件是字节序列，InnoDB数据文件通常很大，整体打开后则是一个超长的字节数组，并不方便进行整体解析，或者数据文件远超内存大小，全部载入内存不太可能，需要对其逐步读取，或者说叫做进行切割，例如按照页的默认大小进行切割，即将数据文件切割成若干个16k大小的片段（数据文件必然是页大小的整数倍）。

在Golang中，这种数组片段的数据结构叫做切片，即slice。这让人想到早餐面包，一整块面包并不方便抹上果酱，那么可以切成面包片，后续就可以很好的处理了。在解析部分的代码中，会经常的使用结构体和切片这两种数据结构进行解析字节序列。

4.3 页

4.3.1 页结构

在数据文件中，页是以16K大小，即16384 Byte（这是一个默认大小，由innodb_page_size参数控制）的字节序列存储的，一个数据文件包含很多个数据页。在内存中，则以B-tree形式来组织，B-tree的每一个节点，就是一个页，非叶子节点通过指针指向下一层节点（页）。

当事务在记录上加逻辑锁时，在B-tree上则是添加的栓锁（latch）来防止页（在页分裂和收缩时，还可能包含页的父节点）被其他线程修改。标准数据页（INDEX page）包含七个部分，组成结构如下列表格所示[4]。

其中，38个字节长度的File Header在几乎所有类型的页中都存在。其结构包含八个部分，组成结构如下：

而56个字节长度的Page Header包含14个部分，组成结构如下：

以上是对INDEX类型的数据页结构的描述，不再赘述其他类型页。像页中的file hader、page header部分或者其他类型的页，在代码中都会有相应的结构体来描述其数据结构。

更多关于数据页结构信息除了参考官网，还可以参考Jeremy Cole在GitHub上开的一个项目，InnoDB Diagrams[5]。InnoDB Diagrams可能更多的是基于MySQL 5.7版本，但是仍有很好的借鉴意义。

4.3.2 页类型

上文说到InnoDB中大概有30余种类型页，这里只解析了其中6种，主要目的则是解析FIL_PAGE_INDEX中的数据，其余类型页的解析则互有侧重。

• FIL_PAGE_TYPE_FSP_HDR

用于分配、管理extent和page，包含了表空间当前使用的page数量，分配的page数量，并且存储了256个XDES Entry（Extent），维护了256M大小的Extent，如果用完256个区，则会追加生成FIL_PAGE_TYPE_XDES类型的页

• FIL_PAGE_IBUF_BITMAP

用于跟踪随后的每个page的change buffer信息，使用4个bit来描述每个page的change buffer信息

• FIL_PAGE_INODE

管理数据文件中的segement，每个索引占用2个segment，分别用于管理叶子节点和非叶子节点。每个inode页可以存储FSP_SEG_INODES_PER_PAGE（默认为85）个记录(Inode Entry(Segment))。FIL_PAGE_INODE管理段，而段信息管理Extent（区）信息

• FIL_PAGE_SDI

存储Serialized Dictionary Information(SDI, 词典序列化信息), 存储了这个表空间的一些数据字典(Data Dictionary)信息

• FIL_PAGE_INDEX

在内存中构造B-tree所需要的数据就存放在这个类型的页中，B-tree的每一个叶子节点就指向了这样的一个页。结构在各处都有详细介绍，其中的File Header，Page Header部分在上文有介绍。

• FIL_PAGE_TYPE_ALLOCATED

已经分配但还未使用的页，即空页。

4.4 解码

4.4.1 记录解析

编码和解码经常组合出现，但因为我们已经默认拿到了数据文件（完成了编码），不再介绍编码过程。

在本文中的解码，是将字节序列解码为人类可读的字符串。也就是解码为数据在存入数据库时，业务写入时的样子。

通常编程语言会提供encode和decode方法进行编码和解码操作，在这次解析中，是参考MySQL源码后自实现的解码过程。

实际上是按存储数据的字节长度不同，对一个字节长度的数据进行位运算左移（左移位数根据字节长度确定，左移n位就是乘以2的n次方），然后每个字节进行或计算。

这里贴源码来，下列代码是unittest\gunit\innodb\lob\mach0data.h中的一段，是对4个连续字节的数据写入和读取的过程，即mach_write_to_4()函数和mach_read_from_4()函数，可以看到位运算的移位操作。

注意：源码在读取字节数据时，将数据转换为ulint类型，这个类型为无符号类型。

inline void mach_write_to_4(byte *b, ulint n) {
  b[0] = (byte)(n >> 24);
  b[1] = (byte)(n >> 16);
  b[2] = (byte)(n >> 8);
  b[3] = (byte)n;
/** The following function is used to fetch data from 4 consecutive
bytes. The most significant byte is at the lowest address.
@param[in] b pointer to four bytes.
@return ulint integer */
inline ulint mach_read_from_4(const byte *b) {
  return (((ulint)(b[0]) << 24) | ((ulint)(b[1]) << 16) | ((ulint)(b[2]) << 8) |
          (ulint)(b[3]));
}

在写入时对每个字节进行了右移，在读取时则需要左移，这里涉及到了大小端的内容，有兴趣可以选择深入研究，不再过多介绍。

4.4.2 行记录格式

上一小节是对具体记录（对应数据库中列的具体值）的字节解析过程介绍。

那么如何定位到记录（在Index数据页中的User RECORD部分中定位），除了定位到记录数据的页，还受到参数innodb_default_row_format的设置的影响。

MySQL数据记录是以行的形式存储的的，而行记录的格式在MySQL 5.7.9及以后版本，默认值是DYNAMIC。

而在MySQL 5.6之前的版本，这个参数默认值还是COMPACT。innodb通过fsp页（数据文件的的第一个页，类型是FIL_PAGE_TYPE_FSP_HDR）的flags（长度4 byte）的不同bit位来判断表空间的各种属性，比如是否压缩，是否加密，是否为共享表空间、是否是临时表空间等等。

其中决定行格式类型是flags结构中的FSP_FLAGS_WIDTH_ATOMIC_BLOBS属性，在flags长度4 byte的32个bit位置中是第6位。

为减少程序复杂度，这里默认行格式为DYNAMIC（有兴趣可自行深入了解，详细可参考源码：storage\innobase\include\fsp0types.h）。 COMPACT行格式

在记录头信息中，使用5个字节长度来标记，其中有一个delete_mask标记位用来标记当前记录是否已经被删除，更多更详细的行记录格式解释可以参考阿里内核月报： https://www.bookstack.cn/read/aliyun-rds-core/24bcb047feb68f13.md 每行记录都按照以上格式存储数据。

DYNAMIC与COMPACT比较类似，不同处在于，对待处理行溢出的处理及策略，Dynamic、Compressed行格式会把记录中数据量过大的字段值全部存储到溢出页中，在原页中保留20字节长度的指针，而不会在该记录的数据内容的相应字段处存储该字段值的768个字节长度的前缀数据了。

在这次解析中不会涉及BLOB等大字段类型，所以解析其实是按照COMPACT格式解析的。

4.5 编写代码

代码水平有限，介绍代码水平更有限，文末会有代码地址，可供详细参考。这里捡重点的简明扼要介绍一下。

4.5.1 打开文件

建议使用只读模式打开文件，对文件进行简单的校验。对文件可对数据页中的checksum值进行校验，这需要按页读取时进行校验，这里偷懒只对文件大小进行了简单校验。打开文件：

file, err := os.OpenFile(filePath, os.O_RDONLY, os.ModePerm)

4.5.2 按页读取

数据文件既然是字节序列，那么其实每次可以读取任意多个字节到内存（如果内存允许），但事实上MySQL数据文件是按页来管理，那么读入内存则以页为单位读取。

在MySQL实例运行时，大部分时候，BTREE的根页（root page）以及第二层甚至第三层的页都是常驻内存的，在主键使用bigint类型时，则非叶子节点中中每个目录项长度是主键8字节长度+指针6字节长度，每个页可存放16384/(8+6)≈1170个目录项，即每个节点的扇出为1170。 那么，BTREE的前几层大小： 第0层：16,384 byte 第1层：16384 * 1170 = 19,169,289 byte 第2层：16384 * 1170 * 1170 = 22,428,057,600 byte

可见前三层的数据大概在20GB左右，将其全部放入内存压力不大，前两层数据甚至只有几十MB而已，BTREE的高度达到4层就可以存放千万条数据。

那么真正需要磁盘读取的数据更可能集中在第2层或以上，因为内存的中页面读取遍历很快，减少磁盘操作，所以效率很高。

在这里解析时，则是按序来读取页，当然可以并发读取，那么解析输出的数据顺序则无法保证了。

// 每读取一页，参数j增加16384，来标记文件的读取位置
now, err := file.Seek(j, io.SeekStart)
// mysql_def.UNIV_PAGE_SIZE=16384
b := make([]byte, mysql_def.UNIV_PAGE_SIZE)
// 读取文件，每读取一页，将其放入数组中存放，Golang读取[]文件会默认将其存储在无符号字节数组中：[]uint8，而Java读取文件会放入有符号数组中：int8[]
n, err := file.Read(b)

4.5.3 构造切片

读取的数据放入数组中，在Golang中，切片是根据动态数组来构建，解析位置会随解析进度变化，据此构造了一个struct：

type Input struct {
 Data     []byte
 Position int64
var IN Input

Input结构体的元素Data用于存放读取文件的字节序列，长度固定为16384。

元素Position则标记解析位置，随解析递增。这样在读取文件后，就可以将字节序列传递给结构体Input的声明变量IN了。

// 每页解析从第0为开始
slice.IN.Position = 0
// 存放数据页字节序列的数组传递给结构体Data元素
slice.IN.Data = b

4.5.4 构造页结构体并解析数据

MySQL数据文件包含不同类型的页，页中包含不同的部分，例如File Header，File Trailer，Page Header等。

对每一种结构都建立与之对应的结构体，这有点类似于Java的面向对象思想。为的是后面解析数据到相同的结构位置时，代码可抽象重用。

这里以File Header为例，在4.3.1节中介绍了它的组成，包含8个部分共38字节长度，对应的结构体如下：

type FilHeader struct {
 PageSpace        int64
 PageOffset       int64
 PagePrev         int64
 PageNext         int64
 PageLsn          int64
 PageType         string
 PageFileFlushLsn int64
 PageArchLogNo    int64
}

因为数据页中每个页在页头都包含File Header，所以对其38个字节长度的解析，总是从第0字节开始到第37位置结束。FileHeader的解析过程如下：

func FileHeaderReadSlice() FilHeader {
  // 声明FilHeader结构体变量
 var fh FilHeader
 fh.PageSpace = slice.ReadUnsignedInt()
 fh.PageOffset = slice.ReadUnsignedInt()
 fh.PagePrev = slice.IfUndefined(slice.ReadUnsignedInt())
 fh.PageNext = slice.IfUndefined(slice.ReadUnsignedInt())
 fh.PageLsn = slice.ReadLongInt64()
 fh.PageType = mysql_def.ParsePageType(slice.ReadShortInt16())
 fh.PageFileFlushLsn = slice.ReadLongInt64()
 fh.PageArchLogNo = slice.ReadUnsignedInt()
 return fh