日志：Redo Log 和 Undo Log

🚀 优质资源分享 🚀

学习路线指引（点击解锁）	知识定位	人群定位
🧡 Python实战微信订餐小程序 🧡	进阶级	本课程是python flask+微信小程序的完美结合，从项目搭建到腾讯云部署上线，打造一个全栈订餐系统。
💛Python量化交易实战💛	入门级	手把手带你打造一个易扩展、更安全、效率更高的量化交易系统

本篇文章主要介绍 Redo Log 和 Undo Log：

1. 利用 Redo Log 和 Undo Log 实现本地事务的原子性、持久性
2. Redo Log 的写回策略
3. Redo Log Buffer 的刷盘时机

日志：Redo Log 和 Undo Log · 语雀 (yuque.com)

通过写入日志来保证原子性、持久性是业界的主流做法。

介绍 Redo Log 和 Undo Log

Redo Log 是什么：Redo Log 被称为重做日志。

Undo Log 是什么：Undo Log 被称为撤销日志、回滚日志。

技术是为了解决问题而生的，通过 Redo Log 我们可以实现崩溃恢复，防止数据更新丢失，保证事务的持久性。也就是说，在机器故障恢复后，系统仍然能够通过 Redo Log 中的信息，持久化已经提交的事务的操作结果。

技术是为了解决问题而生的，Undo Log 的作用 / 功能：

• 事务回滚：可以对提前写入的数据变动进行擦除，实现事务回滚，保证事务的原子性。
• 实现 MVCC 机制：Undo Log 也用于实现 MVCC 机制，存储记录的多个版本的 Undo Log，形成版本链。

Undo Log 中存储了回滚需要的数据。在事务回滚或者崩溃恢复时，根据 Undo Log 中的信息对提前写入的数据变动进行擦除。

---

Redo Log 和 Undo Log 都是用于实现事务的特性，并且都是在存储引擎层实现的。由于只有 InnoDB 存储引擎支持事务，因此只有使用 InnoDB 存储引擎的表才会使用 Redo Log 和 Undo Log。

实现本地事务的原子性、持久性

“Write-Ahead Log”日志方案

MySQL 的 InnoDB 存储引擎使用“Write-Ahead Log”日志方案实现本地事务的原子性、持久性。

“提前写入”（Write-Ahead），就是在事务提交之前，允许将变动数据写入磁盘。与“提前写入”相反的就是，在事务提交之前，不允许将变动数据写入磁盘，而是等到事务提交之后再写入。

“提前写入”的好处是：有利于利用空闲 I/O 资源。但“提前写入”同时也引入了新的问题：在事务提交之前就有部分变动数据被写入磁盘，那么如果事务要回滚，或者发生了崩溃，这些提前写入的变动数据就都成了错误。“Write-Ahead Log”日志方案给出的解决办法是：增加了一种被称为 Undo Log 的日志，用于进行事务回滚。

变动数据写入磁盘前，必须先记录 Undo Log，Undo Log 中存储了回滚需要的数据。在事务回滚或者崩溃恢复时，根据 Undo Log 中的信息对提前写入的数据变动进行擦除。

---

“Write-Ahead Log”在崩溃恢复时，会经历以下三个阶段：

• 分析阶段（Analysis）：该阶段从最后一次检查点（Checkpoint，可理解为在这个点之前所有应该持久化的变动都已安全落盘）开始扫描日志，找出所有没有 End Record 的事务，组成待恢复的事务集合（一般包括 Transaction Table 和 Dirty Page Table）。
• 重做阶段（Redo）：该阶段依据分析阶段中，产生的待恢复的事务集合来重演历史（Repeat History），找出所有包含 Commit Record 的日志，将它们写入磁盘，写入完成后增加一条 End Record，然后移除出待恢复事务集合。
• 回滚阶段（Undo）：该阶段处理经过分析、重做阶段后剩余的待恢复事务集合，此时剩下的都是需要回滚的事务（被称为 Loser），根据 Undo Log 中的信息回滚这些事务。

MySQL 中一条 SQL 更新语句的执行过程

以下的执行过程限定在，使用 InnoDB 存储引擎的表

1. 事务开始
2. 申请加锁：表锁、MDL 锁、行锁、索引区间锁（看情况加哪几种锁）
3. 执行器找存储引擎取数据。
4. 1. 如果记录所在的数据页本来就在内存（i