MySQL InnoDB 页损坏数据恢复：数据库起不来时的正确处置顺序

InnoDB 页损坏的典型报错与根因

典型报错包括 Database page corruption、Page checksum mismatch、failed file read of page、space=0,page number=...。根因多为掉电/宕机造成 torn page、存储或文件系统坏块、双写缓冲未生效、误删 ibdata/.ibd/日志，以及备份期间并发写。

第一步永远是「固证」，不是「修复」

1. 立即停止写入，用只读/副本方式保存 /var/lib/mysql、binlog、错误日志；
2. 不要对运行中实例直接拷贝 InnoDB 文件，也不要删 binlog；
3. 用 CHECK TABLE、SHOW ENGINE INNODB STATUS、错误日志定位坏页。

innodb_force_recovery 1-6 是「跳步启动」，不是修复

级别累加：1=跳过坏页、2=停后台线程、3=不回滚未提交事务、4=不做 change buffer merge（可能永久损坏）、5=不读 undo（极易产生父无子/子无父）、6=不做 redo 前滚。官方明确 4 及以上可永久损坏数据文件。能从 ≤3 导出就相对安全，启动成功应立即 mysqldump --single-transaction 分库导出再重建。

离线「考古」：undrop-for-innodb / Percona 工具

适用于 DROP/TRUNCATE、删行、.ibd/ibdata 损坏、表被删后重建为空等场景。流程：stream_parser 按 FIL_PAGE_INDEX 归类页 → sys_parser 重建 DDL → c_parser 把页内记录解析成可导入的数据。必须在离线副本上运行，且不能保证 100% 恢复。

我们的恢复流水线与验收

1. 固证：保留只读证据快照；
2. 分级启动：按损坏类型选择 force recovery 级别与 binlog 区间；
3. 多源拼接：最近备份 + binlog 前滚 + undrop 页解析合并；
4. 验收：行数、主键范围、业务总额、外键一致性自动核对。

常见问题

1. 1MySQL 起不来还能恢复吗？
   多数可以。页损坏通常只是部分页，先固证再分级导出，核心业务表有较高恢复率。切勿反复 force_recovery 试错。
2. 2innodb_force_recovery 用到几级安全？
   尽量 ≤3 级导出；4 级及以上可能永久损坏数据文件，必须在副本上操作并由有经验工程师判断。
3. 3ibdata 损坏还是 .ibd 损坏？
   定位方式不同：共享表空间 ibdata 损坏影响面大，独立 .ibd 相对好处理。先看错误日志里的 space/page no 定位。
4. 4误删表/误删行能找回吗？
   可用 binlog 闪回（binlog2sql/MyFlash）或 undrop-for-innodb 页解析找回，前提是 binlog 保留完整且磁盘未覆盖。
5. 5恢复要多久？费用怎么算？
   固证 + 分级启动 + 多源拼接通常 1-3 个工作日。到店免费检测，出具报告后报价，不成功不收费。企业客户可签保密协议并对公开票。