MySQL表损坏修复需先区分MyISAM或InnoDB：MyISAM看“marked as crashed”报错及.MYD/.MYI文件，InnoDB看“Database page corruption”或ERROR 2013，并用SHOW TABLE STATUS查Engine；MyISAM优先用mysqlcheck --repair --use-frm，InnoDB则逐级尝试innodb_force_recovery 1–6导出数据后重建，修复后须校验行数、关键记录和时间字段等业务逻辑。
MySQL 表损坏不是小概率事件，但多数情况无需重装或全库恢复——REPAIR TABLE、mysqlcheck 和 innodb_force_recovery 这三类手段覆盖了 90% 以上的修复场景。关键在于先判断损坏类型（MyISAM 还是 InnoDB），再选对工具和参数，否则可能让问题恶化。
怎么快速判断是 MyISAM 还是 InnoDB 表损坏？
错误日志和 SQL 报错是最直接线索：
- 看到
Table 'xxx' is marked as crashed and should be repaired→ 基本是 MyISAM - 启动失败时日志出现
InnoDB: Database page corruption on disk或查询卡死、返回ERROR 2013 (HY000): Lost connection to MySQL server during query→ 大概率是 InnoDB - 用
SHOW TABLE STATUS LIKE 'table_name'查看Engine字段，确认引擎类型 - MyISAM 表对应磁盘文件是
.MYD+.MYI；InnoDB 表依赖ibdata1或独立表空间.ibd
MyISAM 表损坏：用 mysqlcheck 比 REPAIR TABLE 更稳
REPAIR TABLE 只能在连接正常时执行，且不支持并发访问；而 mysqlcheck 可离线操作、支持批量、还能自动跳过只读表。生产环境优先用它：
mysqlcheck -u root -p --repair --use-frm database_name table_name
常用组合参数说明：
-
--repair：执行修复（等价于REPAIR TABLE） -
--use-frm：强制用.frm文件重建索引（当.MYI完全损坏时必需） -
--quick：只检查索引文件头，速度快但不彻底 -
--force：遇到错误不停止，适合批量修复
⚠️ 注意：--use-frm 会丢弃所有索引数据并重建，如果原 .MYD 也损坏，可能丢失部分行记录。
InnoDB 表损坏：别急着删 ibd 文件，先试 innodb_force_recovery
InnoDB 没有类似 MyISAM 的“修复命令”，核心思路是：用最小恢复级别启动 mysqld，导出还能读的数据，再重建表。关键配置在 my.cnf：
[mysqld] innodb_force_recovery = 1
取值范围是 1–6，从低到高逐步尝试（每次改完必须重启 MySQL）：
-
1：忽略崩溃的回滚段，跳过事务回滚 → 多数锁表/事务卡死适用 -
2：阻止主线程运行（如 purge、change buffer 合并）→ 避免后台写入干扰 -
3：不进行事务回滚，跳过插入缓冲合并 → 适合严重页损坏但主键还能查 -
4+：禁用撤消日志、限制 SELECT → 数据完整性风险陡增，仅作最后手段
成功启动后立即执行：
mysqldump -u root -p --single-transaction database_name table_name > table_backup.sql
⚠️ 切记：innodb_force_recovery > 0 时禁止执行 INSERT/UPDATE/DELETE，否则可能引发二次损坏。
修复后必须验证：CHECK TABLE 不等于万事大吉
CHECK TABLE 只能确认结构层面无报错，不能保证业务逻辑正确。真正要做的有三件事：
- 对比修复前后
SELECT COUNT(*)结果，确认行数没丢 - 抽样查几条关键业务记录（比如最新订单、用户余额），看字段值是否合理
- 检查外键约束是否仍生效：
SELECT * FROM information_schema.KEY_COLUMN_USAGE WHERE TABLE_NAME = 'xxx' AND CONSTRAINT_NAME != 'PRIMARY';
最常被忽略的是时间字段异常——比如 datetime 变成 '0000-00-00 00:00:00'，这种在 CHECK TABLE 里完全不会报错，但业务可能已出错。
