mysql中repair的用法_mysql8 参考手册--REPAIR TABLE语句

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.4.3.3节“如果MySQL继续崩溃，该怎么办”和 第16.2.4节“ MyISAM表问题”。

REPAIR TABLE检查表以查看是否需要升级。如果是这样，它将按照与相同的规则执行升级 CHECK TABLE ... FOR UPGRADE。

重要

在执行表修复操作之前，请备份表；在某些情况下，该操作可能会导致数据丢失。可能的原因包括但不限于文件系统错误。请参阅 第7章，备份和恢复。

如果服务器在REPAIR TABLE操作过程中崩溃，则在重新启动服务器后必须立即REPAIR TABLE对表执行另一条 语句，然后再对其执行任何其他操作。在最坏的情况下，您可能有一个新的干净索引文件，而没有有关数据文件的信息，然后执行的下一个操作可能会覆盖数据文件。这是不太可能但可能的情况，强调了首先进行备份的价值。

如果主服务器上的表损坏并REPAIR TABLE在其上运行，则对原始表所做的任何更改都 不会传播到从属服务器。

维修表存储引擎和分区支持

REPAIR TABLE工程 MyISAM， ARCHIVE和 CSV表。对于 MyISAM表，默认情况下它与myisamchk --recover tbl_name具有相同的效果。该语句不适用于视图。

REPAIR TABLE支持分区表。但是，该USE_FRM 选项不能与分区表上的该语句一起使用。

您可以ALTER TABLE ... REPAIR PARTITION用来修复一个或多个分区。有关更多信息，请参见第13.1.9节“ ALTER TABLE语句”和 第23.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

USE_FRM如果.MYI索引文件丢失或其标题损坏，则可以使用 该选项。该选项告诉MySQL不信任.MYI 文件头中的信息，并使用数据字典中的信息重新创建它。myisamchk无法完成这种修复 。

警告

仅当您无法使用常规 模式时才 使用该USE_FRM选项 。告诉服务器忽略文件会使修复过程中无法使用存储在表中的重要表元数据 ，这可能产生有害的后果： REPAIR.MYI.MYI

当前AUTO_INCREMENT值丢失。

表中已删除记录的链接丢失，这意味着此后已删除记录的可用空间将保持不变。

的.MYI报头指示该表是否被压缩。如果服务器忽略此信息，则无法确定表已压缩，并且修复会导致表内容的更改或丢失。这意味着 USE_FRM不应将其与压缩表一起使用。无论如何，这都没有必要：压缩表是只读的，因此它们不应损坏。

如果使用USE_FRM的表是由不同于当前运行的MySQL服务器版本创建的， REPAIR TABLE则不要尝试修复该表。在这种情况下，所返回的结果集REPAIR TABLE包含一个 Msg_type值为 error和的 Msg_text行Failed repairing incompatible .FRM file。

如果USE_FRM使用， REPAIR TABLE则不要检查表以查看是否需要升级。

维修台输出

REPAIR TABLE 返回具有下表所示列的结果集。

列 值

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升级表，如果它包含在预5.6.4格式老时间列(TIME， DATETIME，和 TIMESTAMP列不为小数精度秒支持)和 avoid_temporal_upgrade系统变量被禁用。如果 avoid_temporal_upgrade启用，则REPAIR TABLE忽略表中存在的旧时态列，并且不升级它们。

要升级包含此类临时列的表，请avoid_temporal_upgrade在执行之前将其禁用 REPAIR TABLE。

您可以REPAIR TABLE通过设置某些系统变量来提高性能。