能救回来，但必须按顺序操作：立即停写入→备份数据目录→从innodb_force_recovery=1逐级尝试启动→用mysqldump或select into outfile导出→移除参数→重建实例，跳过任一环节都可能导致数据不可逆损坏。
能救回来，但必须按顺序操作，跳过任何一步都可能让数据彻底不可逆损坏。
看到“InnoDB: Database page corruption”就该停手，别重启、别删文件
这类错误不是配置问题，而是 InnoDB 在 crash recovery 阶段发现上一次 shutdown 非正常（比如 kill -9、断电、虚拟机快照回滚），且当前 redo log 或数据页已不一致。此时强行 mysqld --initialize 或清空 /var/lib/mysql 会直接破坏元数据结构，连抢救机会都没了。
- 先确认错误日志位置：
/var/log/mysql/error.log或/var/lib/mysql/hostname.err，用sudo tail -n 50 hostname.err快速定位最后一段报错 - 重点搜索关键词：
MY-012562、MY-013183、InnoDB: Database was not shut down normally、page number XXXX in space Y - 检查
datadir权限是否为mysql:mysql，并确认ibdata1和ib_logfile0存在且大小合理（比如ib_logfile0不是几 KB）
备份完再改配置，只写 innodb_force_recovery = 1 这一行
修复前不备份 = 主动删库。哪怕只剩 3 分钟，也必须执行：
3-Tier Auto-Backup Daily Snapshots, Drive Mirror & Emergency Recovery
下载
三层自动备份：每日时间戳快照、次级硬盘镜像、紧急对话导出。
-
systemctl stop mysql（确保服务已停） -
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，不要加注释、不要写多个值、不要混入其他配置
从级别 1 开始逐级试，每级最多等 2 分钟
innodb_force_recovery 不是“越大越好”，它是递进式破坏开关：数值越大，跳过的恢复步骤越多，数据一致性风险越高。级别 4 及以上会让 InnoDB 进入永久只读模式，且可能损坏二级索引。
- 级别 1：
innodb_force_recovery = 1—— 跳过损坏页读取，适合单表物理页损坏；能连上就立刻导出 - 级别 3：
innodb_force_recovery = 3—— 跳过事务回滚，多数崩溃场景首选；此时INSERT/UPDATE/DELETE全部被拒绝，但SELECT可用 - 级别 4：
innodb_force_recovery = 4—— 缓冲池不刷新、禁止 DDL，仅用于导出；mysqldump会因禁止写入失败，需改用SELECT ... INTO OUTFILE - 每次修改后必须
sudo systemctl restart mysql（不是reload），然后验证：mysql -uroot -e "SHOW DATABASES;"；若返回空或报错ERROR 2013 (HY000)，立即换下一级
导出后必须移除参数并重建实例，不能带参长期运行
成功导出只是第一步。innodb_force_recovery 是抢救开关，不是运行模式。即使级别 1 能查到数据，也不代表所有页都完好——有些逻辑损坏在导出时不会暴露，但会在后续使用中爆发。
- 导出完成后，**立刻注释或删除**
my.cnf中的innodb_force_recovery行 - 删掉旧数据目录中的
ib_logfile*和ibdata1（仅当确定无其他实例共用该目录时） - 重启 MySQL，让它自动生成干净的日志和系统表空间
- 用
mysql命令重建库表，再导入 dump 文件；注意secure_file_priv限制导出路径：SELECT @@secure_file_priv;，只能导到该路径下
最容易被忽略的是：即使 innodb_force_recovery = 1 能执行 SELECT，也不等于数据完整可用——它只是绕过了校验，没修复损坏本身。
