redo log保障持久性，undo log保障原子性与一致性：前者是物理日志，记录数据页修改以支持崩溃恢复；后者是逻辑日志，记录修改前旧值以支持回滚和MVCC快照读。
MySQL 的 InnoDB 存储引擎依靠 redo log 和 undo log 协同保障事务的原子性与持久性，二者不是互为逆操作，而是分工明确、各司其职的日志机制。
Redo log：确保“已提交的数据不丢”
它是一种物理日志，记录的是“数据页被修改了什么内容”，比如“将页号 123 中偏移量 48 处的字节从 0x1A 改为 0x2F”。核心目标是崩溃恢复——只要事务成功提交，对应 redo 日志已刷盘，即使随后 MySQL 宕机，重启时也能重放这些日志，把缓冲池中尚未写入磁盘的脏页重新构造出来。
- 采用 Write-Ahead Logging（WAL）机制：先写日志，再改内存（Buffer Pool），最后异步刷盘数据页
- 日志写入内存中的 redo log buffer，由 innodb_flush_log_at_trx_commit 参数控制刷盘时机（0/1/2）
- 存储在固定大小的循环文件中（如 ib_logfile0、ib_logfile1），写满后自动覆盖最旧日志（前提是对应数据页已刷盘）
- 只对 InnoDB 生效，MyISAM 等引擎无此日志
Undo log：支撑“回滚 + 多版本读”
它是一种逻辑日志，记录的是“修改前的数据是什么”，例如“某行原值为 name='张三', age=25”。主要用途有两个：一是事务回滚时按链表逆序恢复原始状态；二是 MVCC（多版本并发控制）中，为不同隔离级别的 SELECT 提供快照读所需的旧版本数据。
- 每条 INSERT/UPDATE/DELETE 操作都会生成对应的 undo 记录，并存入 undo tablespace（可配置独立表空间）
- undo 日志按事务组织成链表，每个版本通过 roll_ptr 指针串联，回滚时顺链撤销
- 事务提交后，undo 日志不会立即删除，需等待 purge 线程确认无活跃事务需要该版本后才清理
- UPDATE 会生成两条 undo：一条用于回滚当前更新，一条用于后续可能的二级索引更新
两者如何配合完成一次事务
以 UPDATE t SET x=10 WHERE id=1 为例：
- 事务开始，分配 undo slot，记录 id=1 原来的 x 值（如 x=5）到 undo log
- 修改 Buffer Pool 中对应数据页，同时生成一条 redo log（描述“页内某偏移处写入10”）并写入 log buffer
- 事务 COMMIT 时，redo log 强制刷盘（取决于配置），标记事务为已提交
- 若此时崩溃，重启后通过 redo log 把 x=10 的修改重做到数据页；若事务未提交就崩溃，则用 undo log 将 x 回退为 5
- 其他事务读取该行时，若需一致性读（如 REPEATABLE READ），InnoDB 会根据事务启动时的 read view 查找对应版本的 undo 记录
