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

王竹峰

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

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

---

日志的意义

上面已经讲述过，日志是在逻辑事务对数据库做 DML 操作时，其所包含的物理事务 MTR 所记录的，针对所有涉及的 Buffer Pool 页面的修改记录。

为了更好的讲述日志的意义，这里通过以下几个方面来更好地说明。

假如没有写日志

假如没有写日志，那数据库在做了任何修改之后，必须要直接将 Buffer Page 刷磁盘，不然如果此时数据库挂了，即使事务已经被提交，这些修改还是没办法恢复。这将带来的灾难是，IO 大量增加。此时的数据库，相当于是一个简单的文件系统，无论写什么数据，都必须马上刷入磁盘，Buffer Pool 的作用可能只是一个用来修改文件页面的临时缓存而已。

假如没有写日志，在数据库做了 DML 操作之后，数据库可能在事务没有提交时就将 Buffer Page 刷到磁盘了，但此时需要回滚。而我们知道，回滚段的内容也是通过 Buffer Pool 管理的，它的每个页和 B 树页面是一样的，只是作用不一样而已。由此可知，回滚段数据也是通过 REDO 日志来保证完整性的。那么如果没有了日志，Buffer Page 中的回滚段页面也需要直接写入，没有了任何缓存，性能就会非常低。

假如没有写日志，数据库在关闭（挂掉）后再启动时，就不需要做 REDO 操作了（因为没有写日志），但需要做 UNDO 操作，因为 UNDO 不是通过 REDO 来恢复的，而是自己写入（假设每次写 Buffer Page 之后都直接刷盘了），所以回滚段是有效的，还可以让没有提交的事务回滚掉（因为如果一个事务修改的页面很多的话，肯定会有一部分页面先被刷掉，所以有可能需要回滚），勉强还可以保证数据库的完整性。

综合上面的假设，现在已经明白，日志的作用就是用来保证 Buffer Pool 页面的数据写入不丢失。反过来说，如果每个 Buffer Pool 中的 Page 每次都刷入到磁盘中，这样就不需要 REDO 日志了，此时的数据库就成了一个文件系统，因为 Buffer Pool 每次都进行刷盘，相当于每次写完直接写文件。所以说，日志是数据库管理系统与文件系统最核心的区别。

所以如果没有日志，数据库的性能就低到完全没有办法用了。因为 IO 太大了，同时，这种 IO 操作都是随机写入，很容易导致 IO 到达瓶颈，所以为了提高数据库性能，就必须要使用 REDO 日志机制。

使用日志能提高性能的关键原因，有以下三个方面。

• 因为日志是用来记录 Buffer Pool 中 Page 的修改记录的，所以把对 Page 的写入转化为对日志的写入，那此时 Page 就不需要每次都刷盘，写 Page 页面只需要在内存中写入即可，性能会非常好。

• 通常，一个页面是 16KB，如果不写日志的话，每次的写入单位还是 16KB，即使修改很少量的数据，也是如此。这样会导致无效 IO 非常严重，反过来说，也只有通过日志机制，才能真正体现出真实写入的数据量，不会存在对 IO 的浪费，Page 的刷盘数量会大大减少。

• 如果没有日志，就会每次都刷 Page，而这些 Page 的相对位置是乱的，并不是顺序的，刷盘大多都是随机 IO，这对于机械硬盘来说，性能是非常差的，而有了日志ÿ