全方位解读 MySQL 日志实现内幕（二）

` 王竹峰

去哪儿网数据库专家，擅长数据库开发、数据库管理及维护，一直致力于 MySQL 数据库源码的研究与探索，对数据库原理及实现具有深刻的理解。曾就职于达梦数据库，多年从事数据库内核开发的工作，后转战人人网，任职高级数据库工程师，目前在去哪儿网负责 MySQL 源码研究与运维、数据库管理和自动化运维平台设计开发及实践工作，是 Inception 开源项目及《MySQL 运维内参》的作者，也是 Oracle MySQL ACE。

本文作者将出版于《MySQL 运维内参》中部分内容进行分享，通过多篇文章连载形式，全方位介绍 MySQL 日志实现内幕，可持续关注我们的推文哦！

---

REDO LOG 日志文件管理的用途

REDO LOG 是用来做数据库 crash recovery 的，这是数据库保障数据安全的重要功能之一。在数据库操作中，它保存了对 InnoDB 表中数据的修改记录，所以也叫日志文件。在 InnoDB 存储引擎中，一般默认包括 2 个日志文件，新建数据库之后，会有名为 ib_logfile0 和 ib_logfile1 的两个文件，如果在启动数据库时，这两个文件不存在，则 InnoDB 会根据配置参数或默认值，重新创建日志文件。

在 InnoDB 内部的日志管理中，一个很重要的概念是 LSN，全名叫 Log Sequence Number，它用来精确记录日志位置信息，且是连续增长的。在 InnoDB 中，大小为 8 个字节的值，它的增长量是根据一个 MTR（mini-transaction，后面会讲到）写入的日志量来计算的，写多少日志（单位字节），LSN 就增长多少。日志文件轮循一圈（所有日志文件是以循环方式使用的），那么 LSN 的增长量大约就是整个日志文件的大小（日志文件存在文件头等会占用一部分空间）。它是一个集逻辑意义与物理意义于一身的概念。而在有些数据库中，LSN 是一个完全逻辑的概念，每提交一个物理事务，LSN 就加 1。

上面提到，日志文件是以类似循环圈的方式使用的，如下图所示。

图1

在 InnoDB 中，通过日志组来管理日志文件，是一个逻辑定义，包含若干个日志文件，一个组中的日志文件大小相等，大小通过参数来设置。现在 InnoDB 只⽀持一个日志组。在 MySQL5.5 及之前的版本中，整个日志组的容量不能大于 4GB（实际上是 3.9GB 多，因为还有一些文件头信息等），到了 MySQL 5.6.3 版本之后，整个日志组的容量可以设置得很大，最大可以达到 512GB。

REDO 日志的写入，都是字节连续的，虽然看上去是多个日志文件，但理解的时候，完全可以把它想象成一个文件，对每一文件掐头去尾，把剩下的空间连接起来，就是总的日志空间了。

日志组中的每一个日志文件，都有自己的格式，内部也是按照大小相等的页面切割，但这里的页面大小是 512 个字节，由于历史的原因，考虑到机械硬盘的块大小是 512 字节，日志块大小也如此设计。这是因为写日志其实就是为了提高数据库写入吞吐量，如果每次写入是磁盘块大小的倍数，效率才是最高的，并且日志将逻辑事务对数据库的分散随机写入转化成了顺序的 512 字节整数倍数据的写入，这样就大大提高了数据库的效率。正是因为这个原因，REDO 日志才可以说是数据库管理系统与通过直接写文件来管理数据的最根本的区别之一。

下面展示的是日志文件的格式。

需要注意的是，图中第一列指的是每一项在页面中的偏移位置，而下一项则是这个值加上该值在页面中所占长度得到的值。

图2

图2中展示的 4 个页面（2048 字节），主要用于管理日志内容及整个数据库状态。在这 2KB 内容之后，就是正常的用来存储日志内容的部分，也是按照 512 字节页面大小的方式存储，下方图3中展示的是正常日志页面的格式。