事务日志通过redo log和undo log保障MySQL崩溃恢复。1. Redo log确保已提交事务的持久性，系统重启后重放日志完成未写入数据文件的修改；2. Undo log用于回滚未完成事务并支持MVCC，恢复时清理中间状态；3. 两者协同实现数据库一致性恢复，提升可靠性与性能。
在MySQL中，事务日志（主要是InnoDB存储引擎的重做日志redo log和回滚日志undo log）是实现数据持久性和一致性的重要机制。当数据库发生异常宕机或崩溃时，事务日志能帮助系统恢复到一个一致且可靠的状态，避免数据丢失或损坏。
重做日志（Redo Log）保障已提交事务不丢失
Redo Log记录了数据页的物理修改操作。当事务提交时，对应的修改会被写入redo log，并在后续刷入磁盘的数据文件中。即使在事务提交后、数据尚未写入数据文件前系统崩溃，MySQL重启后可以通过重放redo log中的记录，将未写入磁盘的更改重新应用，从而保证已提交事务的持久性。
关键作用包括：- 确保事务的“持久性”：只要事务提交成功，其影响就不会因系统故障而消失
- 支持快速恢复：重启时只需重放redo log中从检查点之后的操作，无需重新执行所有事务
- 提高写性能：允许数据异步写入磁盘，先写日志再写数据（WAL，Write-Ahead Logging）
回滚日志（Undo Log）支持事务回滚与MVCC
Undo Log保存了数据修改前的旧值，主要用于事务回滚和多版本并发控制（MVCC）。如果事务执行过程中被中断或显式回滚，InnoDB可以利用undo log将数据恢复到事务开始前的状态。
在数据恢复中的价值体现在：
- 崩溃后清理未完成事务：MySQL重启时会识别未提交的事务，并通过undo log将其回滚，保持数据一致性
- 维护一致性视图：在恢复期间，隔离未提交的更改，防止脏数据被永久保留
事务日志协同工作实现崩溃恢复
MySQL启动时会自动进入恢复模式，结合redo log和undo log完成崩溃恢复流程。
典型恢复过程如下：- 通过redo log重做所有已提交但未写入数据文件的更改
- 扫描事务状态，识别未提交的事务
- 使用undo log回滚这些未完成事务的影响
- 最终使数据库达到一个逻辑一致的状态
基本上就这些。事务日志不是备份，但它为MySQL提供了自动、高效的故障恢复能力，是保障数据安全的核心机制之一。合理配置日志大小和刷新策略，能显著提升系统的稳定性和恢复速度。
