innodb页损坏需通过innodb_force_recovery导出数据而非repair table；先确认引擎、查错误日志定位损坏页，再逐级启用innodb_force_recovery(1-6)，启动后立即mysqldump导出，最后手动修复自增id和外键。
CHECK TABLE 报 Corrupt 不代表一定能修，先得搞清是哪类损坏、在哪一层出的问题
查错误日志确认是物理页损坏还是逻辑状态标记
MySQL 的 CHECK TABLE 返回 Corrupt 时，Msg_text 内容才是关键线索：
- 出现
Database page corruption或failed file read of table→ InnoDB 物理页损坏（.ibd 文件中某个 16KB 页校验失败） - 出现
Table is marked as crashed或Incorrect key file→ MyISAM 表状态标记或索引文件（.MYI）损坏 - 只报
Found 1 delete link或Size of datafile is: X Should be: Y→ 数据文件碎片或长度不一致，未必是严重损坏
务必执行：SHOW VARIABLES LIKE 'log_error'; 找到日志路径，再用 grep -i "corrupt\|crashed\|page.*[0-9]" /var/log/mysql/error.log 检查。没在日志里看到对应表名 + 关键词，大概率不是真损坏，而是权限、SQL mode 或残留 .frm 文件干扰。
区分引擎：MyISAM 和 InnoDB 的 Corrupt 含义完全不同
CHECK TABLE 对两类引擎的检查深度和修复路径天差地别：
- MyISAM：检查 .MYD（数据）和 .MYI（索引）文件结构，
REPAIR TABLE能重建索引、跳过坏记录，甚至支持USE_FRM强制按表结构恢复 - InnoDB：
CHECK TABLE实际只校验主键索引一致性，不扫描所有数据页；报Corrupt很可能只是“发现某页读不出来”，但真实损坏位置在 ibdata1、redo log 或 undo log 中 - 执行
SHOW CREATE TABLE your_table;确认ENGINE=值——如果是InnoDB，立刻放弃REPAIR TABLE，它会直接报错Storage engine for the table doesn't support repair
别信 CHECK TABLE 的“轻量”假象：InnoDB 页损坏要靠 innodb_force_recovery 捞数据
当 CHECK TABLE 报 Corrupt 且日志确认是 Database page corruption，说明底层存储已不可靠：
-
SELECT *可能还能返回部分行，但任何WHERE、ORDER BY、JOIN或写入都可能触发崩溃 - 此时目标不是“修复”，而是“抢数据”：必须停写、设
read_only=ON，然后在/etc/my.cnf的[mysqld]段加innodb_force_recovery = 1并重启 - 从 1 试到 6，每次改完必须重启；级别 ≥4 时
INSERT/UPDATE/DELETE被禁用，但mysqldump仍可用 - 能连上就立刻执行：
mysqldump --single-transaction --routines --triggers your_db your_table > backup.sql
导出后删表重建，再导入——这是 InnoDB 页损坏下唯一可控的路径。指望 CHECK TABLE 给出修复建议？它不会告诉你页号、不会定位 ibd 偏移，更不会绕过损坏页继续扫描。
容易被忽略的干扰项：CHECK TABLE 报 Corrupt 但实际是元数据或配置问题
很多“损坏”其实是表定义或环境层面的错位，CHECK TABLE 会误报：
-
SHOW TABLE STATUS LIKE 'your_table';中Comment列显示Crashed，但该表其实是 MyISAM，而你正在用 InnoDB 连接器访问 - 表被
DROP后残留.frm文件，CHECK TABLE尝试解析时失败，报Can't find file类错误 -
sql_mode含STRICT_TRANS_TABLES，导致某些隐式转换失败，CHECK TABLE在验证默认值时卡住 - 字符集不匹配：建表用
utf8mb4，但客户端连接用latin1，CHECK TABLE解析字段定义时校验失败
真损坏往往伴随服务异常（启动失败、查询随机 hang）、磁盘 I/O 错误或 RAID 报警；单靠一条 CHECK TABLE 结果就开修，反而容易把还能读的数据弄丢。
