MySQL 重做日志（redo log）与回滚日志（undo logo）的简单示例

这篇文章主要为大家详细介绍了MySQL 重做日志（redo log）与回滚日志（undo logo）的简单示例，具有一定的参考价值，可以用来参考一下。

感兴趣的小伙伴，下面一起跟随四海网的小玲来看看吧！

前言：

前面文章讲述了 MySQL 系统中常见的几种日志，其实还有事务相关日志 redo log 和 undo log 没有介绍。相对于其他几种日志而言， redo log 和 undo log 是更加神秘，难以观测的。本篇文章将主要介绍这两类事务日志的作用及运维方法。

1.重做日志（redo log）

我们都知道，事务的四大特性里面有一个是 持久性 ，具体来说就是只要事务提交成功，那么对数据库做的修改就被永久保存下来了，不可能因为任何原因再回到原来的状态。那么 MySQL 是如何保证一致性的呢？最简单的做法是在每次事务提交的时候，将该事务涉及修改的数据页全部刷新到磁盘中。但是这么做会有严重的性能问题，主要体现在两个方面：

• 因为 Innodb 是以页为单位进行磁盘交互的，而一个事务很可能只修改一个数据页里面的几个字节，这个时候将完整的数据页刷到磁盘的话，太浪费资源了。
• 一个事务可能涉及修改多个数据页，并且这些数据页在物理上并不连续，使用随机 IO 写入性能太差。

因此 MySQL 设计了 redo log ，具体来说就是只记录事务对数据页做了哪些修改，这样就能完美地解决性能问题了(相对而言文件更小并且是顺序IO)。

redo log 包括两部分：一个是内存中的日志缓冲（redo log buffer），另一个是磁盘上的日志文件（redo log file）。MySQL 每执行一条 DML 语句，先将记录写入 redo log buffer ，后续某个时间点再一次性将多个操作记录写到 redo log file 。

默认情况下，redo log 在磁盘上由名为 ib_logfile0 和 ib_logfile1 的两个物理文件展示。redo log 相关参数简单介绍如下：

• innodb_log_files_in_group：redo log 文件的个数，命名方式如：ib_logfile0，iblogfile1... iblogfilen。默认2个，最大100个。
• innodb_log_file_size：单个 redo log 文件设置大小，默认值为 48M，最大值为512G，注意最大值指的是整个 redo log 系列文件之和，即（innodb_log_files_in_group * innodb_log_file_size ）不能大于最大值512G。
• innodb_log_group_home_dir：指定 redo log 文件组所在的路径，默认./ ，表示在数据库的数据目录下。
• innodb_log_buffer_size：redo log buffer 大小，默认16M。延迟事务日志写入磁盘，把 redo log 放到该缓冲区，然后根据 innodb_flush_log_at_trx_commit 参数的设置，再把日志从 buffer 中 flush 到磁盘中。
• innodb_flush_log_at_trx_commit：控制 redo log 刷新到磁盘的策略，默认为1。值为1，每次 commit 都会把 redo log 从 redo log buffer 写入到 system ，并 fsync 刷新到磁盘文件中。值为2，每次事务提交时 MySQL 会把日志从 redo log buffer 写入到 system ，但只写入到 file system buffer，由系统内部来 fsync 到磁盘文件。如果数据库实例 crash ，不会丢失 redo log，但是如果服务器 crash，由于 file system buffer 还来不及 fsync 到磁盘文件，所以会丢失这一部分的数据。值为0，表示事务提交时不进行写入 redo log 操作，这个操作仅在 master thread 中完成，而在 master thread 中每1秒进行一次重做日志的 fsync 操作，因此实例 crash 最多丢失1秒钟内的事务。

更改 redo log 及其 buffer 大小是需要重启数据库实例的，建议初始化时做好评估。可以适当加大 redo log 组数和大小，特别是你的数据库实例更新比较频繁的情况下。但也不推荐 redo log 设置过大。

2.回滚日志（undo log）

undo log 主要用于保证数据的原子性，保存了事务发生之前的数据的一个版本，可以用于回滚。比如一条 INSERT 语句，对应一条 DELETE 的 undo log ，对于每个 UPDATE 语句，对应一条相反的 UPDATE 的 undo log ，这样在发生错误时，就能回滚到事务之前的数据状态。同时，undo log 也是 MVCC (多版本并发控制) 实现的关键。

MySQL 5.7 版本中，undo log 默认存放在共享表空间 ibdata 中。也可以在初始化时通过配置参数改成独立的文件，简单介绍几个 undo log 相关参数：

• innodb_max_undo_log_size：控制最大 undo tablespace 文件的大小，当启动了innodb_undo_log_truncate 时，undo tablespace 超过 innodb_max_undo_log_size 阀值时才会去尝试truncate。该值默认大小为1G，truncate后的大小默认为10M。
• innodb_undo_tablespaces：设置 undo 独立表空间个数，范围为0-128，5.7版本默认为0，0表示不开启独立undo表空间。该参数只能在最开始初始化 MySQL 实例的时候指定。
• innodb_undo_directory：设置 undo 表空间的存放目录，默认数据目录。
• innodb_undo_log_truncate：设置 undo 表空间是否自动截断回收。该参数生效的前提是，已设置独立表空间且独立表空间个数大于等于2个。

undo log 相关参数一般很少改动。MySQL 8.0 默认启用了独立表空间，可能 undo log 表空间的大小设置更灵活些。

总结：

本篇文章主要介绍了 redo log 及 undo log 的作用和相关参数设置，文章写的比较匆忙，如有错误，可以留言指出。关于这两类日志更深层次的内容，可能笔者功力还不到，未能写到更加透彻。好了，MySQL 相关日志的两篇文章已经写完了，希望各位能学到一点知识。

本文来自：http://www.q1010.com/177/20704-0.html

注：关于MySQL 重做日志（redo log）与回滚日志（undo logo）的简单示例的内容就先介绍到这里，更多相关文章的可以留意四海网的其他信息。

关键词：