图解MySQL【日志】——RedoLog

Redo Log（重做日志） 为什么需要 Redo Log？ 1. 崩溃恢复 数据库崩溃时，系统通过 Redo Log 来恢复尚未写入磁盘的数据。Redo Log 记录了所有已提交事务的操作，系统在重启后会重做这些操作，以保证数据不会丢失。

---

2. 提高性能 使用 Redo Log 可以避免每次修改都立即写入磁盘（随机写），而是先将修改操作写入 Redo Log（顺序写），然后将数据写入内存，最后再异步地将数据写入磁盘，减少了磁盘 I/O 的次数，提高了性能。 3. 事务一致性 即使数据库在执行过程中崩溃，Redo Log 也可以帮助恢复所有已提交的事务，确保数据库恢复到一致（Consistency）的状态。

---

Redo Log 是什么？ Redo Log 是物理日志，记录了某个数据页做了什么修改，如对 AAA 表空间中的 BBB 数据页 CCC 偏移量的地方做了 DDD 更新，每当执行一个事务，就会产生一条或多条物理日志。在事务提交时，只要保证 Redo Log 被持久化到磁盘即可，可以不需要等到将缓存在 Buffer Pool 里的脏页数据持久化到磁盘。即使系统崩溃，Redo Log 已完成持久化，等待 MySQL 重启后，可以根据 Redo Log 的内容，将所有数据恢复到最新状态。

---

WAL（Write-Ahead Logging）技术 核心思想 先写日志：修改数据之前，先将修改操作记录到日志文件中，之后择机再写到磁盘中。崩溃恢复：这样即使崩溃，数据也能通过日志恢复到一致的状态。顺序写 VS 随机写：Redo Log 采用顺序循环写的方式，写入磁盘的速度远大于直接写入磁盘的顺序写方式。

---

过程如图

---

Redo Log 的持久化过程 1. Redo Log Buffer 在事务执行过程中，产生的 Redo Log 也不是直接刷盘的，而是先写入 Redo Log Buffer，后续再择机刷入磁盘中。默认大小为 16MB，可通过 innodb_log_Buffer_size 参数动态调整大小，增大时，可以让 MySQL 处理【长事务】时不必写入磁盘，提升写 I/O 性能。

---

2. Redo Log 什么时候刷盘？

缓存在 Redo Log Buffer 中的 Redo Log 还是在内存中，刷盘时机如下：

MySQL 正常关闭时。Redo Log Buffer 中记录的写入量大于总内存空间（由 innodb_log_Buffer_size 控制）的一半时，触发落盘。 超过一半就落盘的原因：在性能和数据安全之间找到一个平衡点。 InnoDB 的后台线程每隔 1s，将 Redo Log Buffer 持久化到磁盘。每次提交事务时，将 Redo Log Buffer 持久化到磁盘，由 innodb_flush_log_at_trx_commit 参数控制。

---

3. innodb_flush_log_at_trx_commit 参数

决定 Redo Log 的刷盘时机。

0 ：每次事务提交，将 Redo Log 留在 Redo Log Buffer 中，该模式下，事务提交时不会主动触发落盘操作。 写入磁盘时机：等待 InnoDB 后台线程每隔 1s，先写入 OS 的 Page Cache，后调用 fsync() 持久化到磁盘。数据安全性：MySQL 崩溃时，会导致上 1s 所有事务数据丢失。

---

1（默认）：每次事务提交，将缓存在 Redo Log Buffer 中的 Redo Log 直接持久化到磁盘中。 安全性：该模式可以保证 MySQL 异常重启后，数据不会丢失。

---

2：每次事务提交时，都只将缓存在 Redo Log Buffer 中的 Redo Log 写到 Redo Log 文件（OS 的 Page Cache，系统文件缓存），而非磁盘。 写入磁盘时机：等待 InnoDB 后台线程每隔 1s，调用 fsync() 将 Page Cache 中的 Redo Log 持久化到磁盘。数据安全性：MySQL 崩溃时不会导致数据丢失，只有在 OS 崩溃或系统断电的情况下，丢失上 1s 所有事物数据。

---

数据安全性对比：参数 1 > 参数 2 > 参数 0

---

写入性能对比：参数 1 < 参数 2 < 参数 0

---

每种参数对应的写入过程

4. Redo Log 怎样写入？ 重做日志文件组（Redo Log Group）： 默认情况下，InnoDB 存储引擎有一个 Redo Log Group，该重做日志文件组由 2 个 Redo Log 文件组成，且每个 Redo Log File 的大小固定且一致，如下图

---

循环写： Redo Log Group 是以循环写方式工作的，即从头开始写，写到末尾再循环到开头，相当于环形。

具体过程：Redo Log 是避免防止 Buffer Pool 中的脏页丢失而设计的，但随着系统运行，Buffer Pool 中的脏页逐步被刷新到磁盘中，Redo Log 也需要更新自己的空间，擦除已刷新到磁盘中的旧记录，为新的脏页数据腾出空间。

write pos：Redo Log 当前记录写到的位置。check point：表示当前要擦除的位置。write pos~check point（红色部分）：用来记录新的更新操作。 write pos 追上 check point 时表示 Redo Log 文件已满，这时 MySQL 不能执行新的更新操作，即被阻塞（故大并发量的系统，将 Redo Log 文件大小设置为适当的值很有必要），此时会停下来将 Buffer Pool 中的脏页数据刷新到磁盘中，然后标记 Redo Log 哪些记录可以被擦除，接着对旧 Redo Log 记录进行擦除，等擦除完成并腾出空间后，check point就会往后移动，MySQL 恢复正常，继续执行新的更新操作。 check point~write pos（蓝色部分）：待落盘的脏数据页记录。 一次 check point 的过程就是脏页数据刷新到磁盘中变成干净页，然后标记 Redo Log 记录中哪些记录可以被覆盖的过程。

---