崩溃后mysql无法启动，应先查看错误日志定位问题，搜索my-012562、my-013183等关键词确认innodb损坏；必须先完整备份数据目录，再逐级尝试innodb_force_recovery=1至4启动导出数据，成功后立即移除该参数并重建实例。
崩溃后MySQL无法启动，先看错误日志定位问题
直接打开 MySQL 错误日志（通常是 /var/log/mysql/error.log 或 /usr/local/mysql/data/your_host.err），搜索关键词 MY-012562、MY-013183、InnoDB: Database was not shut down normally 或 Log scan progressed past the checkpoint lsn。这些是典型非正常关机引发的 InnoDB 损坏信号。如果看到 ib_logfile0 校验失败或页访问越界（如 page number 3489660288 in space 0），说明日志或系统表空间已损坏，不能跳过日志重建直接试 innodb_force_recovery。
必须先备份，再改配置启动
修复前不备份 = 主动删库。哪怕只剩 5 分钟，也执行：
-
systemctl stop mysqld（或service mysql stop） -
cp -r /var/lib/mysql /var/lib/mysql_backup_$(date +%Y%m%d_%H%M)（路径按实际调整） - 确认备份完整：检查
ls -la /var/lib/mysql_backup_*/ibdata1是否存在且大小合理
备份完才编辑 /etc/my.cnf，在 [mysqld] 下只保留一行有效配置：innodb_force_recovery = 1。不要同时写多个级别，也不要加注释行干扰解析。
从 innodb_force_recovery=1 开始逐级尝试
每次修改后必须重启服务并验证是否能连上：
- 级别 1（
innodb_force_recovery = 1）：跳过损坏页读取，适合单表物理页损坏。能连上就立刻mysqldump导出关键库 - 级别 3（
innodb_force_recovery = 3）：跳过事务回滚，多数崩溃场景首选。此时INSERT/UPDATE/DELETE全部被拒绝，但SELECT可用 - 级别 4（
innodb_force_recovery = 4）：进入只读模式，缓冲池不刷新。仅用于导出，禁止任何 DDL - 超过级别 4（5 或 6）风险陡增：可能跳过校验导致导出数据逻辑错乱，除非级别 4 仍失败且无备份，否则不建议
每级最多试 2 分钟——如果 mysql -u root -p -e "SHOW DATABASES;" 返回空或报错 ERROR 2013 (HY000)，立即停掉服务，换下一级。
导出后必须重建，不能长期带参数运行
innodb_force_recovery 是抢救开关，不是运行模式。一旦成功导出数据：
- 立刻注释或删除配置文件中的
innodb_force_recovery行 - 删掉旧数据目录里的
ib_logfile*和ibdata1（仅当确定无其他实例共用时） - 重启 MySQL，让它自动生成干净的日志和系统表空间
- 用
mysql命令重建库表，再导入 dump 文件
最容易被忽略的是：即使 innodb_force_recovery = 1 能查到数据，也不代表所有页都完好。某些索引页或二级索引可能静默损坏，导出后务必用 CHECK TABLE 在新实例中验证关键表。
