综述

从上层的角度来看,InnoDB层的文件,除了redo日志外,基本上具有相当统一的结构,都是固定block大小,普遍使用的btree结构来管理数据。只是针对不同的block的应用场景会分配不同的页类型。通常默认情况下,每个block的大小为 UNIV_PAGE_SIZE,在不做任何配置时值为16kb,你还可以选择在安装实例时指定一个块的block大小。对于压缩表,可以在建表时指定block size,但在内存中表现的解压页依旧为统一的页大小。

从物理文件的分类来看,有日志文件、主系统表空间文件ibdata、undo tablespace文件、临时表空间文件、用户表空间。

日志文件主要用于记录redo log,InnoDB采用循环使用的方式,你可以通过参数指定创建文件的个数和每个文件的大小。默认情况下,日志是以512字节的block单位写入。由于现代文件系统的block size通常设置到4k,InnoDB提供了一个选项,可以让用户将写入的redo日志填充到4KB,以避免read-modify-write的现象;而Percona Server则提供了另外一个选项,支持直接将redo日志的block size修改成指定的值。

ibdata是InnoDB最重要的系统表空间文件,它记录了InnoDB的核心信息,包括事务系统信息、元数据信息,记录InnoDB change buffer的btree,防止数据损坏的double write buffer等等关键信息。我们稍后会展开描述。

undo独立表空间是一个可选项,通常默认情况下,undo数据是存储在ibdata中的,但你也可以通过配置选项 innodb_undo_tablespaces 来将undo 回滚段分配到不同的文件中,目前开启undo tablespace 只能在install阶段进行。在主流版本进入5.7时代后,我们建议开启独立undo表空间,只有这样才能利用到5.7引入的新特效:online undo truncate。

MySQL 5.7 新开辟了一个临时表空间,默认的磁盘文件命名为ibtmp1,所有非压缩的临时表都存储在该表空间中。由于临时表的本身属性,该文件在重启时会重新创建。对于云服务提供商而言,通过ibtmp文件,可以更好的控制临时文件产生的磁盘存储。

用户表空间,顾名思义,就是用于自己创建的表空间,通常分为两类,一类是一个表空间一个文件,另外一种则是5.7版本引入的所谓General Tablespace,在满足一定约束条件下,可以将多个表创建到同一个文件中。除此之外,InnoDB还定义了一些特殊用途的ibd文件,例如全文索引相关的表文件。而针对空间数据类型,也构建了不同的数据索引格式R-tree。

在关键的地方本文注明了代码函数,建议读者边参考代码边阅读本文,本文的代码部分基于MySQL 5.7.11版本,不同的版本函数名或逻辑可能会有所不同。请读者阅读本文时尽量选择该版本的代码。

文件管理页

InnoDB 的每个数据文件都归属于一个表空间,不同的表空间使用一个唯一标识的space id来标记。例如ibdata1, ibdata2… 归属系统表空间,拥有相同的space id。用户创建表产生的ibd文件,则认为是一个独立的tablespace,只包含一个文件。

每个文件按照固定的 page size 进行区分,默认情况下,非压缩表的page size为16Kb。而在文件内部又按照64个Page(总共1M)一个Extent的方式进行划分并管理。对于不同的page size,对应的Extent大小也不同,对应为:

page sizefile space extent size
4 KiB256 pages = 1 MiB
8 KiB128 pages = 1 MiB
16 KiB64 pages = 1 MiB
32 KiB64 pages = 2 MiB
64 KiB64 pages = 4 MiB

尽管支持更大的Page Size,但目前还不支持大页场景下的数据压缩,原因是这涉及到修改压缩页中slot的固定size(其实实现起来也不复杂)。在不做声明的情况下,下文我们默认使用16KB的Page Size来阐述文件的物理结构。

为了管理整个Tablespace,除了索引页外,数据文件中还包含了多种管理页,如下图所示,一个用户表空间大约包含这些页来管理文件,下面会一一进行介绍。

http://mysql.taobao.org/monthly/2016/02/01/

MySQL · 引擎特性 · InnoDB 文件系统之文件物理结