需先查错误日志判断是否真损坏；若仅进程终止且文件完好，重启即可触发InnoDB自动崩溃恢复，依赖redo log重做已提交事务、undo log回滚未提交事务。
MySQL 崩溃后如何判断是否需要恢复
不是所有“崩溃”都要走恢复流程。先看错误日志（error log），重点找 mysqld got signal 11、Aborting、InnoDB: Database page corruption 这类关键词。如果只是进程被 kill 或 OOM 被系统干掉，但数据文件没损坏，重启 mysqld 往往就能正常起来——InnoDB 会自动执行崩溃恢复（crash recovery）。
InnoDB 崩溃恢复的核心机制是什么
InnoDB 恢复依赖两个关键结构：redo log 和 undo log。
- Redo log 记录了“物理修改”，用于重做已提交但还没刷到 ibdata 或表空间的变更，保证 持久性（Durability）
- Undo log 存在 ibdata 或独立 undo 表空间中，用于回滚未提交事务、构建一致性读视图，支撑 原子性（Atomicity）和隔离性（Isolation）
- 启动时，InnoDB 先读 redo log，把 checkpoint 之后的已提交操作重放一遍；再扫描 undo log，把未提交事务回滚掉
哪些情况会导致自动恢复失败，必须人工介入
自动恢复走不通，通常是因为底层数据已损坏或关键日志丢失：
- redo log 文件（ib_logfile0/1）被误删或损坏，InnoDB 启动时报 Could not open or create the system tablespace 或 log file is missing
- ibdata1 文件损坏，或者页校验失败（checksum mismatch），错误日志出现 page checksum mismatch
- 表空间文件（.ibd）被删、权限异常、或被其他进程锁住，导致 open tablespace 失败
- 配置了 innodb_force_recovery > 0 仍无法启动，说明损坏较严重，需从备份恢复
没有备份时还能抢救吗
能抢一点是一点，但别抱幻想：
- 立刻停止 MySQL，卸载磁盘（如果是云盘，先打快照），避免覆盖式写入
- 用 mysqlcheck --repair 对 MyISAM 表可能有效，但对 InnoDB 基本无效
- 尝试用 innodb_force_recovery=1~6 启动，逐级提高（1 最轻，6 最激进），配合 mysqldump 导出还能读的数据
- 极端情况下可借助工具如 Percona Data Recovery Tool for InnoDB（需熟悉页结构，成功率低、耗时长）
- 记住：没备份 = 没底牌，恢复只是补救，不是替代方案
怎么验证恢复后的数据一致性
不能只看“启动成功”就认为完事：
- 检查 error log 是否还有 warning 或 error，特别是 InnoDB: Error: tablespace mismatch 类提示
- 运行 SELECT COUNT(*) 对核心表比对备份前/后行数（注意事务隔离级别影响）
- 用 pt-table-checksum（需主从）或 mysqldbcompare 校验逻辑一致性
- 抽样查几条关键业务记录（比如最近 1 小时订单、用户登录日志），确认时间戳、状态、金额等字段无跳变或截断
