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=1

2）重启后尽快导出（示例导出单表）：

mysqldump -u root -p your_db your_table > your_table.sql

3）删除/重建表并导入：

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 大版本，我可以直接把修复路线收敛成一套“最小停机、最小风险”的操作清单。