REPAIR TABLE 仅适用于 MyISAM 表，对 InnoDB 无效；使用前须确认表类型、损坏程度、文件完整性及备份可用性，并依情况选择 QUICK（仅修索引）、默认或 EXTENDED（逐行重建）模式。
REPAIR TABLE 在 MySQL 中到底能不能用
多数情况下不能直接用——REPAIR TABLE 仅对 MyISAM 表有效，对 InnoDB 表执行会报错 Storage engine for the table doesn't support repair。MySQL 8.0+ 默认引擎是 InnoDB，所以一上来就跑 REPAIR TABLE 很可能直接失败。
真正能修的场景很窄：只有明确知道表是 MyISAM、且损坏类型属于索引文件（.MYI）出错或数据文件（.MYD）轻微逻辑错时，才可能成功。
-
MyISAM表需处于非只读状态，且用户有RELOAD权限 - 若表被其他线程锁住，命令会阻塞；加
LOCAL修饰符可跳过部分锁检查（但不推荐线上随意用） - 修复过程会重建索引，期间表不可写，读操作也可能被阻塞
MyISAM 表修复前必须做的三件事
盲目执行 REPAIR TABLE 可能把还能抢救的数据彻底覆盖掉。先确认损坏程度和备份状态：
- 用
myisamchk -s /var/lib/mysql/dbname/tablename.MYI检查索引文件，-s是安全模式，不修改任何内容 - 确认
datadir下对应表的.frm、.MYD、.MYI三个文件都存在且未被截断（可用ls -l看大小是否异常小） - 确保最近一次
mysqldump或物理备份可用——REPAIR TABLE EXTENDED会尝试逐行重建数据，一旦出错可能丢数据
常见错误现象：Table 'dbname.tablename' is marked as crashed and should be repaired，这是 MySQL 启动或查询时自动检测到的，不是 REPAIR 的触发条件，只是提示。
REPAIR TABLE 的三种模式怎么选
参数差异直接影响结果可靠性与耗时，不是越“强力”越好：
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
-
REPAIR TABLE tablename：默认模式，只修复索引，快但不管数据行损坏（比如.MYD文件里某几行乱码） -
REPAIR TABLE tablename QUICK：只重build索引，不扫描数据文件，适用于确认数据完好、仅索引失效的情况 -
REPAIR TABLE tablename EXTENDED：逐行读取.MYD并写入新文件，再重建索引——最慢，但能处理部分数据页损坏；若遇到无法解析的字节流，会跳过该行并记录警告
性能影响明显：EXTENDED 模式在百万行表上可能持续数分钟，期间磁盘 I/O 和 CPU 占用飙升，别在业务高峰跑。
InnoDB 表损坏了怎么办
直接放弃 REPAIR TABLE。InnoDB 自身有崩溃恢复机制，优先让 MySQL 重启时自动恢复：
- 确认
innodb_force_recovery未设为非 0 值（否则可能跳过关键恢复步骤） - 检查错误日志里是否有
InnoDB: Database was not shut down normally，有则说明上次异常退出，重启后会自动做 crash recovery - 如果仍报
Tablespace is missing或Corrupted page，只能从备份恢复；或者用mysqlcheck --repair配合--use-frm（极危险，仅当 .ibd 文件丢失但 .frm 还在时尝试）
容易被忽略的一点：InnoDB 表损坏往往源于底层存储故障（如磁盘坏道），修完表不换硬盘，很快又坏。得先查 dmesg | grep -i "ata\|error" 和 smartctl -a /dev/sdX。
