mysql的InnoDB存储引擎通过崩溃恢复机制，在数据库异常重启后自动将数据和事务状态恢复到一致状态，整个过程不需要人工干预，核心依赖redo日志和undo日志两类日志文件。
InnoDB崩溃恢复的核心前提
InnoDB采用WAL（Write Ahead Log）机制，所有数据页的修改都会先写入redo日志，再异步刷到磁盘的数据页中。同时未提交事务的修改会记录undo日志，用于事务回滚。这两类日志是崩溃恢复的基础。
崩溃恢复的完整流程
1. 日志扫描阶段
数据库重启后，InnoDB首先会扫描redo日志文件，找到最后一个检查点（checkpoint）的位置，检查点之前的数据页修改已经全部刷到磁盘，不需要恢复。从检查点之后的redo日志开始作为恢复的起点。
2. redo日志重做阶段
从起点开始顺序读取redo日志，将其中记录的未刷盘的数据页修改重新应用到内存的数据页中，这个过程叫做前滚。即使事务没有提交，只要对应的修改已经写入redo日志，都会被重做，保证所有已写入日志的修改都不会丢失。
以下是模拟redo日志应用的简化逻辑示例：
# 模拟redo日志重做逻辑
def redo_apply(redo_logs, checkpoint_lsn):
current_lsn = checkpoint_lsn
for log in redo_logs:
if log.lsn > current_lsn:
# 将日志中的修改应用到对应数据页
page_id = log.page_id
modify_content = log.modify
data_page = get_data_page(page_id)
data_page.apply_modify(modify_content)
current_lsn = log.lsn
return current_lsn
3. undo日志回滚阶段
redo重做完成后，内存中可能存在未提交事务的修改，这些修改不符合事务的持久性要求，需要通过undo日志进行回滚。InnoDB会遍历所有活跃的事务，根据undo日志的记录，将数据页恢复到事务开始前的状态，这个过程叫做回滚。
4. 事务状态整理
回滚完成后，InnoDB会清理所有未完成事务的相关信息，将已提交事务的修改正式生效，最终数据库恢复到一致状态，可以正常对外提供服务。
崩溃恢复的关键参数
以下参数会影响崩溃恢复的行为和效率：
| 参数名 | 作用 |
|---|---|
| innodb_flush_log_at_trx_commit | 控制redo日志的刷盘策略，设置为1时每次事务提交都刷盘，崩溃恢复时数据丢失风险最低 |
| innodb_log_file_size | 单个redo日志文件的大小，过小的日志文件会导致检查点频繁触发，影响恢复效率 |
| innodb_undo_logs | undo日志的数量，数量不足可能导致长事务回滚时出现问题 |
常见问题说明
- 崩溃恢复的时间取决于检查点之后的redo日志量，日志量越大恢复时间越长
- 如果redo日志文件损坏，可能导致崩溃恢复失败，需要提前做好日志文件的备份
- 未提交事务的修改在redo重做后会被undo回滚，不会出现脏数据
注意：不要手动删除InnoDB的redo日志或undo日志文件，否则会导致崩溃恢复失败，甚至数据损坏。