详解InnoDB存储引擎redo log 和 undo log-CSDN博客

在MySQL的InnoDB存储引擎中，redo log和undo log是支持事务ACID特性的核心机制。它们通过不同的方式记录事务的修改，确保数据的可靠性、一致性以及崩溃恢复能力。以下是它们的详细介绍：

写入顺序：事务执行过程中，InnoDB会先将数据页的修改记录到内存中的redo log buffer。
刷盘时机：事务提交时，redo log从buffer写入磁盘（具体由参数innodb_flush_log_at_trx_commit控制）。
崩溃恢复：
- 数据库启动时，如果发现脏页（内存中修改但未写入磁盘的数据页）未持久化，会通过redo log重放这些修改，恢复数据一致性。
- 例如：假设事务修改了某行数据但未刷盘，系统崩溃后重启，InnoDB会通过redo log将该修改应用到数据页。

假设执行一条SQL语句：

UPDATE account SET balance = 1000 WHERE id = 1;

逻辑日志：记录的是逆向操作（如INSERT对应DELETE，UPDATE对应反向UPDATE）。
随机写入：存储于系统表空间的**回滚段（Rollback Segment）**中，可能涉及随机IO。
生命周期：
- 事务提交后，undo log不会立即删除，而是由Purge线程异步清理。
- 在MVCC中，未被读取事务引用的旧版本数据才会被清除。

记录逆向操作：
- 在事务修改数据前，InnoDB会将旧值写入undo log。
- 例如：UPDATE account SET balance = 1000 WHERE id = 1时，undo log会记录balance=原值。
事务回滚：
- 如果事务回滚，InnoDB会根据undo log中的逆向操作，将数据恢复到修改前的状态。
MVCC支持：
- 通过undo log链表保存数据的多个版本，不同事务根据隔离级别读取对应的历史版本。
- 例如：事务A读取数据时，若其他事务B正在修改该数据，A会通过undo log获取数据修改前的版本，避免冲突。

假设执行一条SQL语句：

UPDATE account SET balance = 1000 WHERE id = 1;

undo log记录：balance字段的旧值（如500）及反向操作（如UPDATE account SET balance = 500 WHERE id = 1）。
作用：
- 若事务回滚，通过undo log将balance恢复为500。
- 若其他事务需要读取该行数据的历史版本（如MVCC），通过undo log获取旧值。

事务提交的两阶段提交：
1. Prepare阶段：将事务的修改写入redo log（标记为prepare状态）。
2. Commit阶段：将事务的修改写入binlog，再更新redo log为commit状态。
- 这确保了redo log和binlog的一致性，避免数据不一致问题。
持久性保障：
- undo log的修改也会生成redo log，确保undo log本身在崩溃恢复后仍然可用。
MVCC实现：
- undo log保存数据的历史版本，结合事务的隔离级别（如可重复读），提供一致性读。

以转账操作为例：

事务开始：
- 扣减账户A的余额（balance -= 100）。
- 增加账户B的余额（balance += 100）。
undo log记录：
- 记录账户A的旧余额（如1000）和反向操作（balance += 100）。
- 记录账户B的旧余额（如500）和反向操作（balance -= 100）。
redo log记录：
- 记录账户A和账户B的数据页修改（物理操作）。
事务提交：
- redo log刷入磁盘，确保持久性。
崩溃恢复：
- 如果系统崩溃，重启后通过redo log恢复已提交的转账操作。
回滚操作：
- 如果事务失败，通过undo log将账户A和B的余额恢复到原始值。