答案：MySQL InnoDB通过Redo Log和Undo Log实现崩溃恢复，先重放日志确保已提交事务持久化，再回滚未提交事务保证一致性。
MySQL InnoDB的崩溃恢复机制确保数据库在异常关闭或系统崩溃后能自动恢复到一致状态。这个过程主要依赖于重做日志（redo log）和回滚段（undo log），通过两阶段的恢复流程完成数据持久性和事务一致性保障。
1. 崩溃恢复的核心组件：Redo Log 和 Undo Log
Redo Log 记录了数据页的物理修改，用于重放已提交但未写入磁盘的事务操作。InnoDB采用WAL（Write-Ahead Logging）机制，所有修改必须先写日志再改数据页。
Undo Log 存储事务回滚所需的信息，是逻辑日志，记录的是行的旧值。它用于事务回滚以及MVCC（多版本并发控制）。
崩溃恢复过程中，Redo Log负责前向恢复（REDO），Undo Log负责后向清理（UNDO）——即回滚未提交事务。
2. 恢复过程的第一阶段：REDO 日志重放
InnoDB启动时会检查磁盘上的数据页和Redo Log的状态，判断是否需要恢复。该阶段目标是将数据库恢复到崩溃前的物理一致性状态。
- 读取Redo Log文件（如ib_logfile0、ib_logfile1），找到最后一个检查点（checkpoint）之后的日志记录
- 按LSN（Log Sequence Number）顺序解析并重放日志，将未写入数据文件的页修改重新应用到表空间
- 即使涉及未提交事务的操作也会被重做，因为这些修改可能已刷盘，不能简单丢弃
此阶段完成后，所有已提交事务的更改都体现在数据页中，但可能存在部分未提交事务的残留修改，需通过Undo Log清理。
3. 恢复过程的第二阶段：UNDO 回滚未提交事务
REDO完成后，InnoDB进入事务恢复阶段，重点是处理崩溃时尚未提交的事务。
- 扫描Undo Logs，识别出处于“active”状态的事务（即未提交也未回滚）
- 根据事务的Undo信息，逆向执行其修改操作，将数据恢复到事务开始前的状态
- 每个事务的回滚由独立的回滚段管理，支持并发恢复处理
这一步确保数据库达到ACID中的原子性和一致性要求。
4. 恢复结束与服务启动
当REDO和UNDO阶段全部完成后，InnoDB认为数据已恢复至一致状态。
- 清理事务系统和锁系统的内存结构
- 打开数据字典，加载表空间元数据
- 启动后台线程（如purge线程、master thread等）
- 允许用户连接，恢复正常服务
整个过程对用户透明，无需手动干预，除非日志损坏导致无法解析。
基本上就这些。InnoDB的崩溃恢复机制设计得非常稳健，只要Redo Log和数据文件不同时损坏，通常都能自动恢复。关键是保持日志文件完整，并合理配置innodb_flush_log_at_trx_commit和sync_binlog等参数来平衡性能与安全性。
