MySQL探索：InnoDB的磁盘文件和磁盘传输机制

如何将数据保存到磁盘，如何利用日志文件保证数据不丢失，如何将数据保存到磁盘不仅是诸如此类的数据库的关键技术MySQL，也是用于MQ消息队列或其他中间软件的关键技术之一。

上图详细展示了InnoDB存储引擎的架构。从图中可以看出，InnoDB存储引擎由三个主要部分组成：内存池、后台线程和磁盘文件。接下来我们简单了解一下磁盘文件相关的概念和原理。 InnoDB中主要的磁盘文件主要分为三大块：一是系统表空间，二是用户表空间，三是重做日志文件和归档文件。二进制文件（binlog）等文件是MySQL Server层维护的文件，因此不包含在InnoDB磁盘文件中。

系统表空间和用户表空间

InnoDB系统表空间包含InnoDB数据字典（元数据和相关对象）以及双写缓冲区、更改缓冲区和撤消日志的存储区域。系统表空间默认还包含任何用户在系统表空间中创建的表数据和索引数据。系统表空间是一个共享表空间，因为它被多个表共享

系统表空间由一个或多个数据文件组成。默认情况下，在MySQL数据目录中创建一个初始大小为10MB、名为ibdata1的系统数据文件。用户可以使用innodb_data_file_path来配置数据文件的大小和数量。

innodb_data_file_path 的格式如下：

innodb_data_file_path=datafile1[,datafile2]...
复制代码

用户可以通过多个文件组成一个表空间，同时指定文件的属性：

innodb_data_file_path = /db/ibdata1:1000M;/dr2/db/ibdata2:1000M:autoextend
复制代码

这里我们说的是两个文件 /db/ibdata1 和 / dr2/db/ibdata2组成系统表空间。如果两个文件位于不同的磁盘上，则可以平均磁盘上的负载，从而提高数据库的整体性能。两个文件的文件名后面都是属性，表示文件ibdata1的大小为1000MB，文件ibdata2的大小为1000MB，并且它们在空间用完后可以自动增长（autoextend）。

设置innodb_data_file_path参数后，基于InnoDB存储引擎的表中的数据将注册到系统表空间中。如果设置了innodb_file_per_table参数，用户可以基于InnoDB存储引擎为每个表生成一个独立的用户表。空间。用户表空间的命名约定是：tablename.ibd。这样，用户不需要将所有数据存储在标准系统表空间中，但用户表空间只存储表中的数据、索引、插入缓冲区BITMAP等信息，其余信息仍然存储在标准系统表空间中表空间。

上图展示了InnoDB存储引擎如何存储文件。 frm文件是表结构定义文件，记录了每个表的表结构定义。

重复日志文件和归档文件

默认情况下，InnoDB存储引擎的数据目录中有两个文件，名为ib_logfile0和ib_logfile1。这就是InnoDB重做日志文件（redo log fiel），它记录了InnoDB存储引擎的事务日志。当InnoDB的数据存储文件发生错误时，重做日志文件会很有用。 InnoDB存储引擎可以利用重做日志将数据恢复到正确的状态，保证数据的正确性和完整性。

每个InnoDB存储引擎至少有1个重做日志文件组（group），每个文件组至少有2个重做日志文件，如默认的ib_logfile0和ib_logfile1。为了更高的可靠性，用户可以设置多个镜像日志组，将不同的文件组放在不同的磁盘上，以提高恢复日志的高可用性。

日志组中每个重做日志文件的大小一致，并且以循环写入的方式运行。 InnoDB存储引擎首先写入重做日志文件1，当文件满时，切换到重做日志文件2。当重做日志文件2也满时，切换到重做日志文件1。

用户可以使用innodb_log_file_size来设置redolog文件的大小，对InnoDB存储引擎的性能影响很大。

如果重做日志文件设置得太大，数据丢失时恢复可能需要很长时间。另一方面，如果设置太小，则redolog文件会太小，导致基于检查点的频繁检查。将脏页刷新到磁盘会导致性能抖动。 redologs和Checkpoint相关的机制可以阅读我之前文章的相应章节。 MySQL探索（三）：InnoDB的内存结构及特点

重做日志放置机制

InnoDB遵循WAL（Write advance redo log）和Force-log-at-来刷新数据文件和日志文件有两种提交规则，分别是：两者都保证了交易的持久性。WAL要求在将数据更改写入磁盘之前，必须先将登录内存写入磁盘； Force-log-at-commit 要求提交事务时，所有生成的日志必须刷新到磁盘。如果日志更新成功后，如果在缓冲池中的数据更新到磁盘之前数据库崩溃了，数据库重新启动时可以从日志中恢复数据。

如上图所示，当InnoDB更改缓冲池中的数据时，它会先将相关更改写入redolog缓冲区，然后按时或在事务提交时将其写入磁盘。这与Force-log-at-Commit原则一致；当重做日志写入磁盘时，缓冲池中发生变化的数据会根据检查点机制在合适的时间写入磁盘，这符合WAL原理。在检查点计时机制中，有一个判断redolog文件已满的情况。因此，如上所述，如果重做日志文件太小并且经常已满，则往往会导致检查点将更改的数据写入磁盘。 ，导致性能抖动。

操作系统中的文件系统有缓存。 InnoDB将数据写入磁盘时，只能写入文件系统缓存，并没有真正的“安全”。 InnoDB的innodb_flush_log_at_trx_commit属性可以控制InnoDB在每个事务提交时的行为。当属性值为0时，事务提交时，不会写入重做日志，而是等待主线程及时写入；当该属性值为1时，事务提交时，会将重做日志写入文件系统缓存并调用文件系统的fsync将文件系统缓冲区中的数据真正写入到磁盘存储中，以确保不发生数据丢失；当该属性值为2时，事务提交时日志文件也会写入文件系统。缓存，但不调用fsync，而是让文件系统决定何时将缓存写入磁盘。木头冲水机构如下图所示。

innodb_flush_log_at_commit是一个基本的InnoDB性能调优参数，涉及到InnoDB的写入效率和数据安全性。当参数值为0时，写入效率最高，但数据安全性最低；当参数值为1时，写入效率最低，但数据安全性最高；当参数值为2时，两者都处于中等水平。一般建议将此属性值设置为1，以实现更高的数据安全性，只有设置为1才能保证事务的持久性。

作者：ztwindy
链接：https://juejin.im/post/5b94884af265da0ae74f60d3
来源：掘金
版权归作者所有。商业转载请联系作者获取授权。非商业转载请注明出处。