综述
从上层的角度来看，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 size | file space extent size |
|---|---|
| 4 KiB | 256 pages = 1 MiB |
| 8 KiB | 128 pages = 1 MiB |
| 16 KiB | 64 pages = 1 MiB |
| 32 KiB | 64 pages = 2 MiB |
| 64 KiB | 64 pages = 4 MiB |
尽管支持更大的Page Size，但目前还不支持大页场景下的数据压缩，原因是这涉及到修改压缩页中slot的固定size（其实实现起来也不复杂）。在不做声明的情况下，下文我们默认使用16KB的Page Size来阐述文件的物理结构。
为了管理整个Tablespace，除了索引页外，数据文件中还包含了多种管理页，如下图所示，一个用户表空间大约包含这些页来管理文件，下面会一一进行介绍。