MySQL 9.0 发行说明
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 列，它们不支持小数秒精度。