MySQL在校验阶段通过page checksum和page LSN一致性检查发现页损坏，失败即崩溃而非降级；默认行为是立即终止操作并触发FATAL级崩溃，确保数据一致性优先于可用性。
MySQL如何在校验阶段发现页损坏
InnoDB 在每次读取一个 16KB 数据页（无论是从磁盘加载还是从 buffer pool 中访问）时，都会做两层校验：page checksum 和 page LSN 一致性检查。如果校验失败，就会在错误日志中输出类似 Database page corruption on disk 或 failed file read of page [page id: space=XX, page number=YY] 的信息。这不是偶然报错，而是 InnoDB 主动拦截——它宁可崩溃也不写入或返回不可信数据。
常见触发点包括：
- 磁盘静默错误（silent corruption），比如坏道但未报 I/O error
- 突然断电导致页头或校验和写入不完整
- 内存 ECC 失效后污染了写入缓冲区中的页内容
- 文件系统缓存未刷盘，
fsync被跳过
遇到页损坏时 MySQL 的默认行为是 crash 而非降级服务
一旦校验失败，InnoDB 不会尝试“跳过”或“忽略”该页继续运行。它会立即终止当前操作，并在多数情况下触发 Assertion failure 或 FATAL 级别崩溃，例如日志里出现 We intentionally crash the server to prevent corrupt data from ending up in data files。这是设计使然：InnoDB 把数据一致性放在可用性之上。
这意味着：
- 即使只有单个索引页损坏，
SELECT查询到该页时也会断连（报Error 2013） -
CHECK TABLE会直接返回Msg_text: Database page corruption，而非“warning” - 实例无法启动时，错误日志首条报错往往就是页损坏线索，不是后续衍生问题
innodb_force_recovery 不是修复命令，而是只读逃生开关
innodb_force_recovery 参数本质是让 InnoDB 在启动或运行时绕过某些恢复逻辑，从而“勉强读出还能读的数据”。它不修复任何物理页，也不重算校验和，只是降低校验强度或跳过依赖损坏结构的步骤。
关键实操要点：
- 必须从
innodb_force_recovery = 1开始逐级尝试，不能跳级；=4起自动启用read_only=ON，且可能丢弃未提交事务、跳过 undo 扫描 - 每次修改后必须重启
mysqld，并立刻用mysql -e "SELECT 1"验证是否连得上 - 能连上后优先执行
SHOW TABLE STATUS，Data_length为 0 或远小于预期的表大概率已损坏，导出时应--ignore-table排除 -
mysqldump卡死或报Error 2013时，说明目标表含损坏页，此时分批SELECT * FROM t LIMIT 10000 OFFSET N可能绕开部分损坏区域（但不保证）
真正有效的抢救路径只有“导出 + 重建”，没有在线修复
页损坏发生后，REPAIR TABLE 对 InnoDB 表直接报错 Storage engine for the table doesn't support repair；删 .ibd 文件、手动修改页头、用 myisamchk 处理都完全无效甚至危险。
唯一被验证可行的路径是：
- 停写入 → 加
innodb_force_recovery启动 →mysqldump导出可用数据 → 注释掉该参数并重启 → 删除原库 → 重建库并导入 - 导入后必须手动检查：自增 ID 是否重置（需
ALTER TABLE ... AUTO_INCREMENT = N）、外键是否缺失（mysqldump默认不导出FOREIGN KEY定义）、时间字段是否全变成 0000-00-00 - 若
innodb_force_recovery=6仍无法导出关键表，才考虑用inno_space工具定位并删除损坏页（如./inno -f table.ibd -d 12345），但这属于底层操作，风险极高，必须先备份原始.ibd
最易被忽略的一点：页损坏常是反复发生的信号。第一次报错没处理，第二次可能就卡在系统表空间（ibdata1）上，连 innodb_force_recovery=6 都救不回来——所以看到任何 page corruption 日志，第一反应不是“还能不能修”，而是“哪些数据还来得及捞”。
