RedoLog通过WAL机制和innodb_flush_log_at_trx_commit=1确保事务持久性：每次COMMIT触发fsync落盘，崩溃后重放日志恢复已提交事务；其物理日志特性（顺序写、快、可循环）保障高性能。
RedoLog 是怎么保证事务持久性的
MySQL 的 innodb_flush_log_at_trx_commit 参数直接控制 RedoLog 刷盘时机，它决定事务提交后日志是否真正落盘。设为 1（默认）时，每次 COMMIT 都触发 fsync，确保崩溃后能通过重放 RedoLog 恢复已提交事务——这就是持久性的核心机制。
RedoLog 是物理日志，记录“在某个数据页的某个偏移量上写了什么字节”，不关心 SQL 语义。它写入快、顺序追加、可循环覆盖，因此开销远低于直接刷数据页。
- 若设为 0：日志只写入 OS 缓存，每秒刷一次，崩溃可能丢一秒事务
- 若设为 2：日志写入 OS 缓存并
flush到文件系统 page cache，但不fsync，崩溃时依赖 OS 是否已落盘 - RedoLog 文件大小固定（
innodb_log_file_size×innodb_log_files_in_group），写满会自动切换并触发 checkpoint，推动脏页刷新
UndoLog 存在哪？为什么不能删
UndoLog 不是独立日志文件，而是存储在 ibdata1（或独立表空间中）的 Undo Segment 里，属于 InnoDB 表空间的一部分。它的生命周期由事务可见性规则和 purge 线程共同管理。
一个事务未被所有活跃读视图（read view）完全“看不见”之前，其对应的 UndoLog 就不能被清除。否则，另一个事务做 MVCC 读时会找不到历史版本，导致一致性破坏。
- 长事务会阻塞 purge，导致 Undo Log 持续膨胀，甚至撑爆表空间
-
information_schema.INNODB_TRX中的TRX_STARTED时间可用于识别长事务 - 设置
innodb_max_purge_lag可让大事务主动退避，避免 purge 落后太多
RedoLog 和 UndoLog 在崩溃恢复时各起什么作用
MySQL 崩溃重启后，先重放 RedoLog（recovery phase）：把所有已提交但未刷盘的数据页变更补上；再启动 purge 线程清理无用 UndoLog；最后才允许新事务接入。
注意：RedoLog 不负责回滚未提交事务——那是 UndoLog 的事。崩溃时未提交的事务，其 RedoLog 记录虽存在，但因缺少对应 COMMIT 标记，在 recovery 阶段会被跳过；而这些事务的 UndoLog 仍保留，用于后续 rollback 或 MVCC。
- RedoLog 恢复的是“物理状态”，目标是让数据库回到崩溃前最后一刻的已提交状态
- UndoLog 不参与 crash recovery 的主流程，但它支撑着 crash 后首次打开事务时的回滚操作（如客户端连接后执行
ROLLBACK） - 如果 RedoLog 和 UndoLog 冲突（比如某页被 RedoLog 修改过，但该修改又被对应 UndoLog 标记为可回滚），InnoDB 以 RedoLog 为准——因为 RedoLog 是最终落盘依据
为什么不能用 UndoLog 替代 RedoLog 实现持久性
UndoLog 是逻辑日志（记录“把 ID=5 的 name 从 A 改成 B”），无法支持快速恢复：重放 UndoLog 需要先定位到原始行、判断当前版本、再反向应用，性能极差，且无法处理 DDL 或页分裂等底层变更。
更关键的是，UndoLog 本身也需要持久化保障——它的修改也得记 RedoLog。也就是说，UndoLog 的写入过程，一样依赖 RedoLog 来保证不丢。
- RedoLog 是 WAL（Write-Ahead Logging）机制的载体，所有数据变更必须先记 Redo 才能改内存页
- UndoLog 是 MVCC 和回滚的基础设施，不是 crash-safe 的替代方案
- 试图用 UndoLog 回滚来“模拟”持久性，等于把事务原子性和持久性混为一谈——原子性靠 Undo，持久性靠 Redo
innodb_log_file_size）其实也在间接影响长事务和 purge 效率。 
