Redo 日志保障已提交事务的持久性，Undo 日志保障未提交事务的原子性和MVCC；Redo 记录物理页修改、顺序写入、崩溃后重放前滚，Undo 记录逻辑反向操作、支持回滚与版本读取、异步清理。
Redo 和 Undo 是 SQL 数据库（尤其是 InnoDB 等支持事务的引擎）保障事务 ACID 特性最核心的两个日志机制，它们分工明确、协同工作：Redo 保证已提交事务的持久性（Durability），Undo 保证未提交事务的原子性（Atomicity）和多版本并发控制（MVCC）所需的可重复读（Repeatable Read）。
Redo 日志：确保“写进去就丢不掉”
Redo 记录的是物理层面“数据页做了什么修改”，比如“在 page X 的 offset Y 处写入了新值 Z”。它采用顺序写、预写式（WAL）策略——事务提交前，必须先把对应的 redo 日志刷到磁盘，之后才向客户端返回“提交成功”。即使数据库崩溃，重启时可通过重放（replay）redo 日志，把已提交但尚未刷盘的数据页变更重新应用，从而恢复数据一致性。
- Redo 是循环写入的固定大小日志文件（如 ib_logfile0/1），不随事务增长而无限膨胀
- 只要事务 commit 成功，其修改就“一定”能通过 redo 恢复，哪怕 buffer pool 中的数据页还没写回磁盘
- Redo 不负责回滚；它只做“前滚”，不处理事务失败场景
Undo 日志：支撑“回滚”与“读取旧版本”
Undo 记录的是逻辑层面“事务原本想做什么反向操作”，比如“把某行从值 A 改回 B”。它保存在 undo tablespace 中，按事务生命周期管理。当事务执行 UPDATE 或 DELETE 时，InnoDB 会先将原记录写入 undo log，再修改当前行；若事务中途 ROLLBACK，就用这些 undo 记录把数据还原。
- Undo 还是 MVCC 的基础：SELECT 查询会根据事务启动时的 read view，结合 undo 链找到该时刻可见的行版本
- 长期不提交的大事务会阻碍 undo 日志清理，导致 undo 表空间膨胀，甚至影响其他事务的 purge 进度
- undo 日志在事务提交后不会立即删除，需等待所有可能依赖它的快照事务结束，才由 purge 线程异步回收
Redo 与 Undo 协同保障事务一致性
一个典型事务生命周期中，两者紧密配合：
- 事务开始 → 分配 undo segment，准备写入 undo 记录
- 执行 DML → 先写 undo（保存旧值），再改内存中的数据页，并记录对应 redo（描述页修改）
- 事务 commit → 强制刷写 redo 到磁盘（确保持久性），标记 undo 为“已提交”，但暂不清理
- 崩溃恢复 → 先重放 redo（恢复所有已提交事务的修改），再根据 undo 状态回滚未完成事务（或跳过已提交事务的 undo）
- 后续查询 → 利用 undo 构建历史版本，避免读锁，实现非阻塞一致性读
运维与调优关键点
理解二者协作关系，有助于定位性能与稳定性问题：
- Redo 日志太小（如 innodb_log_file_size 设置过低）会导致频繁 checkpoint，增加 I/O 压力；过大则延长崩溃恢复时间
- Undo 表空间碎片化或配置不当（如 innodb_undo_log_truncate=OFF）可能导致空间无法回收，需定期监控 innodb_undo_tablespaces 和 purge 滞后情况
- 长事务不仅占用 undo，还会拖慢 redo 清理（因 checkpoint 不能推进到该事务 start lsn 之前），应尽量避免
- 高并发短事务下，关注 innodb_log_buffer_size 是否足够，避免频繁 flush log buffer
