MySQL 8.4 版本说明
REPAIR [NO_WRITE_TO_BINLOG | LOCAL]
TABLE tbl_name [, tbl_name] ...
[QUICK] [EXTENDED] [USE_FRM]
REPAIR TABLE 修复可能损坏的表，仅适用于某些存储引擎。
此语句需要对该表拥有 SELECT 和 INSERT 权限。
虽然通常情况下您不应该运行 REPAIR TABLE，但如果发生灾难，此语句很有可能从 MyISAM 表中恢复所有数据。如果您的表经常损坏，请尝试找出原因，以消除使用 REPAIR TABLE 的必要性。参见 第 B.3.3.3 节，“如果 MySQL 持续崩溃该怎么办” 和 第 18.2.4 节，“MyISAM 表问题”.
REPAIR TABLE 检查表以查看是否需要升级。如果是，则执行升级，遵循与 CHECK TABLE ... FOR UPGRADE 相同的规则。有关更多信息，请参见 第 15.7.3.2 节，“CHECK TABLE 语句”.
重要
在执行表修复操作之前，请备份表；在某些情况下，该操作可能会导致数据丢失。可能的原因包括但不限于文件系统错误。请参见 第 9 章，备份和恢复。
如果服务器在执行
REPAIR TABLE操作期间退出，则在重新启动后，必须立即对该表执行另一个REPAIR TABLE语句，然后再对其执行任何其他操作。在最坏的情况下，您可能会有一个新的干净索引文件，而没有关于数据文件的信息，然后您执行的下一个操作可能会覆盖数据文件。这是一种不太可能但可能发生的场景，它强调了先进行备份的价值。如果源上的表损坏，并且您对其运行
REPAIR TABLE，则对原始表所做的任何更改 不会传播到副本。
REPAIR TABLE 对 MyISAM、ARCHIVE 和 CSV 表起作用。对于 MyISAM 表，它与 myisamchk --recover tbl_name 的默认效果相同。此语句不适用于视图。
REPAIR TABLE 支持分区表。但是，USE_FRM 选项不能与分区表的此语句一起使用。
您可以使用 ALTER TABLE ... REPAIR PARTITION 来修复一个或多个分区；有关更多信息，请参见 第 15.1.9 节，“ALTER TABLE 语句” 和 第 26.3.4 节，“分区维护”。
NO_WRITE_TO_BINLOG或LOCAL默认情况下，服务器会将
REPAIR TABLE语句写入二进制日志，以便它们复制到副本。要禁止记录，请指定可选的NO_WRITE_TO_BINLOG关键字或其别名LOCAL。QUICK如果您使用
QUICK选项，REPAIR TABLE尝试仅修复索引文件，而不是数据文件。这种类型的修复类似于 myisamchk --recover --quick 所做的修复。EXTENDED如果您使用
EXTENDED选项，MySQL 会逐行创建索引行，而不是一次使用排序创建一个索引。这种类型的修复类似于 myisamchk --safe-recover 所做的修复。USE_FRM如果
.MYI索引文件丢失或其头损坏，则可以使用USE_FRM选项。此选项告诉 MySQL 不要相信.MYI文件头中的信息，而是使用数据字典中的信息重新创建它。这种类型的修复无法使用 myisamchk 完成。警告仅当您无法使用常规的
REPAIR模式时，才使用USE_FRM选项。告诉服务器忽略.MYI文件会导致存储在.MYI中的重要表元数据无法用于修复过程，这可能会产生有害的后果当前的
AUTO_INCREMENT值将丢失。表中指向已删除记录的链接将丢失，这意味着此后将保留用于已删除记录的空闲空间。
.MYI头指示表是否已压缩。如果服务器忽略此信息，它将无法判断表是否已压缩，修复会导致表内容发生变化或丢失。这意味着USE_FRM不应与压缩表一起使用。无论如何，这应该是没有必要的：压缩表是只读的，因此它们不应该被破坏。
如果您对由与您当前运行的 MySQL 服务器版本不同的 MySQL 服务器版本创建的表使用
USE_FRM，REPAIR TABLE不会尝试修复该表。在这种情况下，REPAIR TABLE返回的结果集将包含一行，其中Msg_type值为error，而Msg_text值为Failed repairing incompatible .FRM file。如果使用
USE_FRM，REPAIR TABLE不会检查表以查看是否需要升级。
REPAIR TABLE 返回一个结果集，其中包含下表所示的列。
| 列 | 值 |
|---|---|
表 |
表名 |
Op |
始终为 repair |
Msg_type |
status、error、info、note 或 warning |
Msg_text |
信息消息 |
对于每个修复的表，REPAIR TABLE 语句可能会生成许多信息行。最后一行具有 Msg_type 值 status，而 Msg_test 通常应为 OK。对于 MyISAM 表，如果您没有获得 OK，则应尝试使用 myisamchk --safe-recover 修复它。（REPAIR TABLE 并未实现 myisamchk 的所有选项。使用 myisamchk --safe-recover，您还可以使用 REPAIR TABLE 不支持的选项，例如 --max-record-length。）
REPAIR TABLE 表会在将表统计信息从旧的损坏文件复制到新创建的文件时捕获并抛出任何发生的错误。例如，如果 .MYD 或 .MYI 文件所有者的用户 ID 与 mysqld 进程的用户 ID 不同，则 REPAIR TABLE 会生成“无法更改文件所有权”错误，除非 mysqld 是由 root 用户启动的。
通过设置某些系统变量，您可能能够提高 REPAIR TABLE 的性能。请参见 第 10.6.3 节，“优化 REPAIR TABLE 语句”。
REPAIR TABLE 会升级表，如果该表包含 5.6.4 之前格式的旧时间列；即，缺少对小数秒精度支持的 TIME、DATETIME 和 TIMESTAMP 列。