MySQL 表损坏如何修复（按引擎给你一套可落地 SOP）🛠️
先讲结论：修复表损坏的关键不在“多跑几条命令”，而在于先分清表是 MyISAM 还是 InnoDB。因为MyISAM 可直接 repair，而InnoDB 的主策略是“恢复可启动 → 导出数据 → 重建表/从备份恢复”。(MySQL开发者专区)
0）硬性原则（先保命，再修复）✅
立刻停止写入（下线业务或切只读），避免损坏扩大。
先做备份：哪怕是拷一份数据目录或做一次导出，也比“边修边坏”强。
1）确认损坏与表引擎（别盲修）🔍
SHOW TABLE STATUS LIKE 'your_table'\G CHECK TABLE your_table;解释：
SHOW TABLE STATUS：确认 Engine（决定后续修复路线）。CHECK TABLE：做一致性检查，帮助确认是否真的损坏，以及损坏级别（MyISAM/部分场景可定位更清楚）。(MySQL开发者专区)
2）修复策略选择表（按场景一眼选对）📌
| 表引擎 | 优先手段 | 停机要求 | 风险 |
|---|---|---|---|
| MyISAM | REPAIR TABLE/mysqlcheck --repair/myisamchk | 中等（myisamchk 建议停库） | 中（可能丢部分索引/行）(MySQL开发者专区) |
| InnoDB | 从备份恢复 + binlog 追日志；或innodb_force_recovery导出后重建 | 高 | 高（强制恢复等级过高可能造成进一步破坏）(MySQL开发者专区) |
3）MyISAM 表修复（能修就直接修）🔧🙂
方案 A：在线修复（最常用）
REPAIR TABLE your_table;解释：
REPAIR TABLE是 MyISAM 的标准修复语句，可修复索引与部分损坏结构（适用于“表被标记为 crashed”等情况）。(MySQL开发者专区)
方案 B：批量修复（运维更省事）
mysqlcheck --repair --databases your_db解释：
mysqlcheck是表维护工具，适合批量检查/修复；对 MyISAM 的 repair 会从数据字典获取结构信息，某些情况下即使.MYI头部有问题也更有机会修复。(MySQL开发者专区)
方案 C：离线强修（更彻底，但要停库）
sudo systemctl stop mysql myisamchk -r /var/lib/mysql/your_db/your_table.MYI sudo systemctl start mysql解释：
myisamchk直接针对 MyISAM 的.MYI/.MYD文件操作，通常要求停库，避免修复过程与 mysqld 并发读写造成二次损坏。(MySQL开发者专区)
4）InnoDB 表损坏修复（核心是“救出数据再重建”）🧯
优先路径：用 备份 + binlog 恢复
解释：
InnoDB 出现物理损坏时，最可靠的是找未损坏备份恢复，然后用二进制日志回放增量变更，完成时间点恢复。(MySQL开发者专区)
应急路径：强制恢复启动 → 导出 → 重建
1）在 MySQL 配置加入（仅应急）：
[mysqld] innodb_force_recovery=12）重启后尽快导出（示例导出单表）：
mysqldump -u root -p your_db your_table > your_table.sql3）删除/重建表并导入：
DROP TABLE your_table; -- 用原建表语句重新建表mysql -u root -p your_db < your_table.sql解释：
innodb_force_recovery只建议在紧急情况下启用，目的就是“让 InnoDB 勉强启动，把表导出来”。务必先备份物理数据副本。(MySQL开发者专区)等级从 1 往上加（1→2→3…），能导出就立刻停；官方明确提示：4 或更高可能导致永久性进一步破坏，生产环境不要盲目上强度。(MySQL开发者专区)
5）收尾验证（修完不验等于没修）✅
CHECK TABLE your_table;解释：
再跑一次检查，确认表结构与索引一致性恢复到可用状态；同时观察业务关键查询是否恢复正常。
如果你把报错日志贴一小段（例如 “marked as crashed” 或 InnoDB 的 page corruption 类信息），再告诉我表引擎（MyISAM/InnoDB）和 MySQL 大版本，我可以直接把修复路线收敛成一套“最小停机、最小风险”的操作清单。
