13.7.2.5 REPAIR TABLE 语句
REPAIR [NO_WRITE_TO_BINLOG | LOCAL]
TABLE tbl_name [, tbl_name] ...
[QUICK] [EXTENDED] [USE_FRM]
REPAIR TABLE仅针对某些存储引擎修复可能已损坏的 table。
该语句要求 table 具有SELECT和INSERT特权。
尽管通常您不必运行REPAIR TABLE，但是如果灾难袭来，此语句很可能从MyISAMtable 中取回所有数据。如果您的 table 经常损坏，请尝试找出原因，以消除使用REPAIR TABLE的需要。参见第 B.4.3.3 节“如果 MySQLcontinue 崩溃该怎么办”和第 15.2.4 节“ MyISAMtable 问题”。
REPAIR TABLE检查 table 以查看是否需要升级。如果是这样，它将按照与检查 table...升级相同的规则执行升级。有关更多信息，请参见第 13.7.2.2 节“ CHECK TABLE 语句”。
Important
-
在执行 table 修复操作之前，请备份 table；在某些情况下，该操作可能会导致数据丢失。可能的原因包括但不限于文件系统错误。参见第 7 章，备份和恢复。
-
如果服务器在REPAIR TABLE操作期间崩溃，则在重新启动服务器后，必须立即对该 table 执行另一个REPAIR TABLE语句，然后对该服务器执行任何其他操作，这很重要。在最坏的情况下，您可能有一个新的干净索引文件，而没有有关数据文件的信息，然后执行的下一个操作可能会覆盖数据文件。这是不太可能但可能的情况，强调了首先进行备份的价值。
-
如果源上的 table 已损坏，并且您在该 table 上运行REPAIR TABLE，则对原始 table 所做的任何更改都不会传播到副本。
REPAIR TABLE 存储引擎和分区支持
REPAIR TABLE适用于MyISAM，ARCHIVE和CSVtable。对于MyISAMtable，默认情况下与myisamchk-恢复 tbl_name具有相同的效果。该语句不适用于视图。
分区 table 支持REPAIR TABLE。但是，USE_FRM选项不能与分区 table 上的该语句一起使用。
您可以使用ALTER TABLE ... REPAIR PARTITION修复一个或多个分区。有关更多信息，请参见第 13.1.8 节“ ALTER TABLE 语句”和第 22.3.4 节“分区维护”。
维修台选项
NO_WRITE_TO_BINLOG或LOCAL
默认情况下，服务器将REPAIR TABLE语句写入二进制日志，以便它们复制到副本。要禁止记录日志，请指定可选的NO_WRITE_TO_BINLOG关键字或其别名LOCAL。
QUICK
如果使用QUICK选项，则REPAIR TABLE尝试仅修复索引文件，而不修复数据文件。这种修复类似于myisamchk-恢复-快速进行的修复。
EXTENDED
如果使用EXTENDED选项，MySQL 将逐行创建索引，而不是一次创建一个索引进行排序。这种修复方式类似于myisamchk --safe-recover。
USE_FRM
如果.MYI索引文件丢失或其标题已损坏，则可以使用USE_FRM选项。该选项告诉 MySQL 不信任.MYI文件头中的信息，并使用.frm文件中的信息重新创建它。 myisamchk无法完成这种修复。
Caution
如果您无法使用常规REPAIR模式，请仅使用USE_FRM选项。告诉服务器忽略.MYI文件会使修复过程中无法使用.MYI中存储的重要 table 元数据，这可能产生有害的后果：
-
当前的
AUTO_INCREMENT值丢失。 -
table 中已删除记录的链接丢失，这意味着此后已删除记录的可用空间将保持不变。
-
.MYIHeaders 指示 table 是否已压缩。如果服务器忽略此信息，则无法确定 table 已压缩，并且修复会导致 table 内容的更改或丢失。这意味着USE_FRM不应与压缩 table 一起使用。无论如何，这都没有必要：压缩 table 是只读的，因此它们不应损坏。
如果将USE_FRM用于由与当前运行的 MySQL 服务器不同版本的 MySQL 服务器创建的 table，则REPAIR TABLE不会尝试修复该 table。在这种情况下，由REPAIR TABLE返回的结果集包含Msg_type值为error和Msg_text值为Failed repairing incompatible .FRM file的行。
如果使用USE_FRM，则REPAIR TABLE不会检查该 table 以查看是否需要升级。
REPAIR TABLE 输出
REPAIR TABLE返回具有下 table 所示列的结果集。
| Column | Value |
|---|---|
Table | table 名 |
Op | 一律repair |
Msg_type | status，error，info，note或warning |
Msg_text | 信息性消息 |
REPAIR TABLE语句可能为每个已修复的 table 产生许多行的信息。最后一行的Msg_type值为status，而Msg_test通常应为OK。对于MyISAMtable，如果未获得OK，则应尝试使用myisamchk --safe-recover对其进行修复。 (REPAIR TABLE不能实现myisamchk的所有选项。对于myisamchk --safe-recover，您还可以使用REPAIR TABLE不支持的选项，例如--max-record-length。)
REPAIR TABLEtable 捕获并引发将 table 统计信息从旧的损坏文件复制到新创建的文件时发生的任何错误。例如。如果.frm，.MYD或.MYI文件的所有者的用户 ID 与mysqld进程的用户 ID 不同，则REPAIR TABLE会生成“无法更改文件所有权”错误，除非root用户启动了mysqld。
table 维修注意事项
REPAIR TABLE如果 table 中包含 5.6.4 之前的格式的旧时态列(TIME，DATETIME和TIMESTAMP列不支持小数秒精度)，则升级 table，并且禁用avoid_temporal_upgrade系统变量。如果启用了avoid_temporal_upgrade，则REPAIR TABLE会忽略 table 中存在的旧时态列，并且不会升级它们。
要升级包含此类临时列的 table，请在执行REPAIR TABLE之前禁用avoid_temporal_upgrade。
您可以通过设置某些系统变量来提高REPAIR TABLE性能。参见第 8.6.3 节“优化 REPAIR TABLE 语句”。
