MySQL崩溃重启时自动执行InnoDB崩溃恢复：先读取ibdata1中flushed_lsn，再前滚重放LSN大于该值的redo log，最后回滚未提交事务；若卡住超30分钟，可能需innodb_force_recovery导出数据。
崩溃后 MySQL 自动启动时到底做了什么
只要没彻底损坏 ibdata1 或 redo log 文件，InnoDB 在实例重启时会自动触发崩溃恢复（crash recovery），不需要人工干预。这个过程不是“修表”，而是按日志重放已提交事务、回滚未提交事务，确保数据页状态与最后一次 checkpoint 一致。
关键动作发生在 mysqld 启动早期：它先从 ibdata1 第一个 page 读取 flushed_lsn（即上次正常 shutdown 时的 checkpoint LSN），再扫描所有 redo log 文件，找出 LSN > flushed_lsn 的日志段，逐条应用——这就是所谓“前滚（redo）”。之后才加载 undo log 回滚未完成事务（undo）。整个流程由 InnoDB 内核自动完成，你看到的“启动慢”，往往就是卡在这一步。
- 如果磁盘 I/O 慢或 redo log 很大（比如几十 GB），恢复可能耗时数分钟甚至更久，但这是正常现象，不是卡死
- 若启动卡在
InnoDB: Starting crash recovery...超过 30 分钟，大概率是 redo log 或系统表空间损坏，需介入 -
innodb_force_recovery不是恢复手段，只是“绕过校验强行启动”的逃生开关，仅用于导出数据，不能设为 6 后长期运行
错误日志里看到 “Page may be an index page” 怎么办
这类报错（如 InnoDB: Page may be an index page where index id is 819620 或 Probable data corruption on page 673268）说明 InnoDB 在刷脏页或读取索引页时发现校验失败，主动 crash 防止写坏盘。它不等于数据全丢了，但意味着至少一个 page 物理损坏。
此时不要急着删库或重装，先确认损坏范围：
- 查错误日志中连续出现的
space=xxx, page number=yyy，确认是单个表还是系统表空间（space=0是 ibdata1，最危险） - 用
mysqlcheck -c database_name table_name检查对应表，但注意：它可能因底层 page 损坏直接报错退出 - 如果只是用户表（
.ibd文件单独存在），可尝试ALTER TABLE table_name IMPORT TABLESPACE配合备份的.cfg文件恢复——前提是损坏前你导出过元数据 - 若
ibdata1损坏且无可用备份，唯一现实路径是启用innodb_force_recovery=1~6逐级尝试导出还能读的数据
innodb_force_recovery 参数怎么设才不翻车
innodb_force_recovery 是把双刃剑：设低了读不出数据，设高了可能跳过关键一致性检查，导致导出的数据本身就有逻辑矛盾（比如主键冲突、外键断裂）。它只应在其他方法全部失效时启用，且必须配合立即导出。
- 从
1开始试，每级增加后都执行mysqldump --single-transaction database_name看能否成功；不要一上来就设6 -
1：跳过 insert buffer 合并；3：跳过 undo log 回滚；4：跳过 insert buffer 和 undo；6：禁用 redo/undo，只读模式 —— 到这一级，很多SELECT都会报错 - 启用该参数后，MySQL 禁止写入（
INSERT/UPDATE/DELETE全部失败），所以 dump 必须用--single-transaction或--lock-tables=false，否则锁表失败 - 导出完成后立刻停服务，改回配置，切勿带着
innodb_force_recovery重启
真正能救命的其实是 shutdown 前那一次 flush
InnoDB 正常关闭时写的那个 flushed_lsn，是整个崩溃恢复的锚点。如果实例是 kill -9 或断电宕机，这个 LSN 就停留在很久以前，恢复就得重放大量日志；而如果能保证优雅 shutdown（比如 systemctl stop mysql），恢复几乎瞬间完成。
生产环境最容易被忽略的一点：别让监控脚本或容器平台用 kill -9 强杀 mysqld。哪怕多等 30 秒，也要走 clean shutdown 流程。另外，定期做 FLUSH LOGS + 备份最近的 redo log，比迷信“自动恢复”靠谱得多。
