在 MySQL 数据库的运作中，事务的处理显得尤为关键，它确保了数据的稳定性、可靠性和一致性。这种保障背后，离不开 Redo Log（重做日志）和 Undo Log（回滚日志）的默契配合。
一、坚固的防线：Redo Log 的职责与工作原理
二、守护者之职：Undo Log 的作用与实现
2. 关键细节：Undo Log 支持多版本并发控制（MVCC），实现事务的隔离性。它通过保留旧数据版本，让其他事务在读取数据时根据不同的隔离级别和 ReadView 判断数据的可见性，避免脏读、不可重复读等问题。而且，即使事务提交后，Undo Log 也不会立即被删除，直到确保没有其他事务需要这些旧版本数据后，才由 Purge 线程清理。
三、协同作战：Redo Log 与 Undo Log 的工作流程
了解了两种日志的原理后，我们来看看它们在一个完整的事务流程中的协同工作。以一个简单的更新操作为例，从开启事务到提交事务，再到后台操作，Redo Log 和 Undo Log 各自发挥作用，共同保障了事务的 ACID 特性。
四、救援行动：崩溃恢复时的 Redo Log 与 Undo Log
当 MySQL 系统遭遇崩溃时，Redo Log 和 Undo Log 会迅速展开救援行动。系统会从最近的 Checkpoint LSN 开始重放 Redo Log，恢复数据到崩溃前的状态。通过扫描事务表和回滚未完成事务的操作，保证数据的一致性。
五、Binlog 的角色与限制
虽然 Binlog 是 MySQL 中另一种重要的日志，用于主从复制和数据恢复，但它并不能替代 Redo Log 和 Undo Log。Redo Log 是 InnoDB 引擎层的物理日志，专为崩溃恢复设计，而 Binlog 记录的是 SQL 语句。为了保证两者的一致性，MySQL 采用了两阶段提交机制。
Redo Log 和 Undo Log 是 MySQL 事务处理的核心机制，它们各自发挥重要作用，又紧密协作，共同保障了数据的稳定性、可靠性和一致性。