MySQL·引擎特性·InnoDB文件系统管理（一）

从上层的角度来看，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。

为了管理磁盘文件的读写操作，InnoDB设计了一套文件IO操作接口，提供了同步IO和异步IO两种文件读写方式。针对异步IO，支持两种方式：一种是Native AIO，这需要你在编译阶段加上LibAio的Dev包，另外一种是simulated aio模式，InnoDB早期实现了一套系统来模拟异步IO，但现在Native Aio已经很成熟了，并且Simulated Aio本身存在性能问题，建议生产环境开启Native Aio模式。

对于数据读操作，通常用户线程触发的数据块请求读是同步读，如果开启了数据预读机制的话，预读的数据块则为异步读，由后台IO线程进行。其他后台线程也会触发数据读操作，例如Purge线程在无效数据清理，会读undo页和数据页；Master线程定期做ibuf merge也会读入数据页。崩溃恢复阶段也可能触发异步读来加速recover的速度。

对于数据写操作，InnoDB和大部分数据库系统一样，都是WAL模式，即先写日志，延迟写数据页。事务日志的写入通常在事务提交时触发，后台master线程也会每秒做一次redo fsync。数据页则通常由后台Page cleaner线程触发。但当buffer pool空闲block不够时，或者没做checkpoint的lsn age太长时，也会驱动刷脏操作，这两种场景由用户线程来触发。Percona Server据此做了优化来避免用户线程参与。MySQL5.7也对应做了些不一样的优化。

除了数据块操作，还是物理文件级别的操作，例如truncate, drop table，rename table等DDL操作，InnoDB需要对这些操作进行协调，目前的解法是通过特殊的flag和计数器的方式来解决。

当文件读入内存后，我们需要一种统一的方式来对数据进行管理，在启动实例时，InnoDB会按照instance分区分配多个一大块内存（在5.7里则是按照可配置的chunk size进行内存块划分），每个chunk又以UNIV_PAGE_SIZE为单位进行划分。数据读入内存时，会从buffer pool的free list中分配一个空闲block。所有的数据页都存储在一个LRU链表上。修改过的block被加到flush_list上，解压的数据页被放到unzip_LRU链表上。我们可以配置buffer pool为多个instance，以降低对链表的竞争开销。

从物理文件到内存管理是一个相对比较庞大的架构，本文将一一为读者进行分析解读，以让读者对InnoDB的文件系统管理有个更加全面的认识。在关键的地方本文注明了代码函数，建议读者边参考代码边阅读本文。

本文的代码部分基于MySQL 5.7.11版本，不同的版本函数名或逻辑可能会有所不同。请读者阅读本文时尽量选择该版本的代码。