Redo Log （重做日志）是保证数据库持久性与一致性的关键。
Redo log 的引入，是为了保证 MySQL 宕机时，数据恢复可以按照顺序的恢复方式，而不是随机读写。
1. Redo log 是什么
Redo Log（重做日志） 是保证数据库事务持久性的一种重要日志记录机制，用于记录已经执行的事务修改操作。
当数据库进行数据修改操作（如插入、更新、删除）时，会对数据本身进行修改，并生成一个对应的重做日志记录。
这个重做日志记录包含了修改的细节。例如，被修改的数据块位置、修改前后的值等。这些日志记录被持久化保存在磁盘上，确保即使系统崩溃，也能通过重做日志来恢复数据的一致性。
例如：
假设有一个银行数据库，其中有一个名为 “accounts” 的表，存储了用户的账户信息。现在有一笔转账操作，用户A将100元转账给用户B。这个操作涉及两个步骤：
- 从用户A的账户中减少100元。
- 向用户B的账户中增加100元。
在这个过程中，数据库会生成两个重做日志记录：
- 重做日志1： 记录从用户A账户减少100元的操作。这个日志会包含被修改的数据块、修改前后的值等信息。
- 重做日志2： 记录向用户B账户增加100元的操作。同样，这个日志会包含相关的修改信息。
在这个过程中，如果系统崩溃了，数据库可以通过 Redo Log 来恢复数据的一致性，Redo Log 会重新执行这两个日志记录中所记录的操作，确保数据库的状态与事务执行前一致。
2. Redo log 的作用
Redo log 的两个主要作用：保持事务的持久性、提高事务的提交效率。
1、保证事务的持久性
Buffer pool 缓冲池中的脏页（脏数据）没有进行刷盘时，如果此时数据库发生 crash，重启服务后，可以通过 Redo log 找到需要重放到磁盘文件的那些数据记录。
2、提高事务的提交效率
将 Buffer pool 中的数据直接刷新到磁盘是一个随机 IO，效率较差。
将 Buffer pool 中的数据记录到 Redo log 是一个顺序 IO，极大提高了事务的提交效率。
例如：执行一条更新语句。
update user set name = 'lisi' where id = 1 --更新前name = 'zhangsan'
Redo log 会用来存 name = ‘lisi’ 这条更新后的新记录，如果刷盘时发生异常，通过 Redo log 可以找到这条记录，再进行重放操作，以保证事务的持久性。
3. Redo log 的结构
Redo log 由 log block、log group 组成。
3.1 log block
Redo log 的存储都是以 块（block） 为单位进行存储的。
每个块由三部分组成：日志块头（log block header）、日志块尾（log block tailer）、日志本身。
每个块是 512 字节，同磁盘扇区大小一致，可以保证块的写入是原子操作。
3.2 log group
一个日志文件由多个块所构成，多个日志文件形成一个重做日志文件组（Redo log group）。
4. Redo log 的工作原理
Redo log 是如何保证事务持久性的呢？下文逐一解析。
4.1 MySQL 基础知识回顾
先回顾下相关的 MySQL 基础知识。
Redo log 日志类型
Redo log 属于物理日志, 只是记录一下事务对数据库做了哪些修改，在数据库重启恢复的时候被使用。
checkpoint
checkpoint （检查点）可以将脏页给刷新回磁盘，当 DB 重启恢复时，只需要恢复 checkpoint 之后的数据，可以极大地提高恢复效率。
checkpoint 主要解决以下几个问题：
- 缩短数据库的恢复时间；
- 缓冲池不够用时，将脏页刷新到磁盘；
- 重做日志不可用时，刷新脏页。
LSN (Log Sequence Number)
LSN 是一个单调递增的值，是 InnoDB 使用的一个版本标记的计数。
数据页和 Redo log 都有各自的 LSN，根据数据页中的 LSN 值和 Redo log 中 LSN 的值，来判断需要恢复的 Redo log 的位置和大小。
4.2 Redo log 的工作原理
Redo log 其实就是存储了数据被修改后的值。
提交一个事务时，InnoDB 会先去把要修改的数据写入日志，再去修改缓冲池里面的真正数据页。
Redo log 是如何一步步写入磁盘的呢？
Redo log 由以下两个部分构成：
- 重做日志缓冲（redo log buffer）：存在于内存中，容易发生丢失，该部分日志是易失性的。
- 重做日志文件（redo log file）：存在于磁盘中，不容易发生丢失，该部分日志是持久的。
这样的设计是为了调和内存与磁盘的速度差异。
发出一条 update 语句写入到 redo log 时的过程：
log buffer 写入到 log file 分为两步：
- 写入操作系统缓存；
- 进行 fsync 操作刷新到磁盘。
InnoDB 的刷盘机制，可以通过innodb_flush_log_at_trx_commit参数进行设置。
1) innodb_flush_log_at_trx_commit 的值为 0
当innodb_flush_log_at_trx_commit 的值为 0 时性能好，由后台 Master 线程每隔 1秒执行一次操作，可能会丢失 master thread 还没刷进磁盘的这一秒内的事务数据。
master thread 是 InnoDB 的一个在后台运行的主线程，master thread 可以实现刷新日志缓冲、合并插入缓冲、刷新脏页等，master thread 中刷新数据，属于checkpoint的一种。
innodb_flush_log_at_trx_commit的值设为 0 ，并不是指 master thread 中不会刷新日志了。master thread 刷新日志是在不断进行的，Redo log 写入磁盘是持续写入的。
2) innodb_flush_log_at_trx_commit 的值为 1（默认值）
当innodb_flush_log_at_trx_commit 的值为1 时，这是最安全、性能最差的方式。
3) innodb_flush_log_at_trx_commit 的值为 2
当innodb_flush_log_at_trx_commit 的值为 2 时，如 DB 发生故障能恢复数据。如果操作系统也出现了宕机，文件系统中没有及时写入磁盘的数据就会丢失。
通常建议取值 2，因为 MySQL 挂了，数据没有损失，整个服务器挂了，才会损失 1 秒的事务提交数据。
宕机恢复
DB 宕机后重启：
首先，InnoDB 会查看数据页中的 LSN 的数值，这个值代表数据页被刷新回磁盘的 LSN 的大小。
接着，InnoDB 会查看 Redo log 的 LSN 的大小。
- 如果数据页中的 LSN 值大，则说明数据页领先于 Redo log 刷新回磁盘，不需要进行恢复。
- 如果数据页中的 LSN 值小，则需要从 Redo log 中恢复数据。
Redo log 记录的是新数据的备份，在事务提交前，只需要将 Redo log 持久化，不需要做数据持久化。
当系统崩溃时，虽然数据没有持久化，但是 Redo log 已经持久化到磁盘中，系统可以根据 Redo log 的内容，将所有数据恢复到最新的状态。
最后，通过下图，加深对 Redo log 工作原理的理解。
5. Redo log 和 Binlog、Undo log 的区别
Bin log、Redo log 和 Undo log 都是 MySQL 数据库极为重要的日志文件，可以说是 MySQL 的内核所在。
Redo log 和 Binlog、Undo log 的主要区别：
2.1 数据记录方式不同
- Bin log：以二进制格式记录数据库的修改操作。
- Redo log：以固定大小的物理日志文件记录数据库页的物理修改。
- Undo log：以逻辑方式记录事务执行过程中旧值的备份。
…….
详解篇，点击蓝字查看：Bin log、Redo log 和 Undo log 的区别
6. 总结
通过本文，我们了解并掌握了 Redo log 的基础概念、内部结构、工作原理，以及与Bin log、Redo log 的区别。
Redo Log 是保证数据库持久性与一致性的关键。Redo log 的作用是保持事务的持久性、提高事务的提交效率。
Redo Log 与 Binlog、Undo log 一样，都是 MySQL 的重要内核，既是必知必会的技能，也是大厂高频面试点。
建议收藏备用，划走就再也找不到了。
如果觉得有用，请顺手【关注+点赞】支持下宝妹儿，拜谢。
PS.
本文已收录于宝妹儿精编的 2023版《MySQL 大厂高频面试题大全》PDF。
《MySQL 大厂高频面试题大全》一共78页，34000字，图文并茂，长期持续更新。
吃透它，足以应对 MySQL 面试。
获取方法：
