13.7.2.5 REPAIR TABLE 语法

REPAIR [NO_WRITE_TO_BINLOG | LOCAL]
    TABLE tbl_name [, tbl_name] ...
    [QUICK] [EXTENDED] [USE_FRM]

维修表修复可能已损坏的 table,仅适用于某些存储引擎。

此语句需要 table 的选择插入权限。

虽然通常你不应该 run 维修表,但如果发生灾难,这个语句很可能会从MyISAM table 中获取所有数据。如果您的表经常损坏,请尝试找到它的原因,以消除使用维修表的需要。见第 B.4.3.3 节,“如果 MySQL 不断崩溃该怎么办”第 15.2.4 节,“MyISAM Table Problems”

维修表检查 table 以查看是否需要升级。如果是,则执行升级,遵循与检查 TABLE ...升级相同的规则。有关详细信息,请参阅第 13.7.2.2 节,“检查 TABLE 语法”

重要

  • 在执行 table 修复操作之前备份 table;在某些情况下,操作可能会导致数据丢失。可能的原因包括但不限于文件系统错误。见第 7 章,备份和恢复

  • 如果服务器在维修表操作期间崩溃,则在重新启动它之后必须立即为 table 执行另一个维修表语句,然后再对其执行任何其他操作。在最坏的情况下,您可能有一个新的干净索引文件,但没有关于数据文件的信息,然后您执行的下一个操作可能会覆盖该数据文件。这是一个不太可能但可能的情况,强调了首先进行备份的值。

  • 在 event 中,master 上的 table 被破坏并且你在其上运行维修表,原始 table 的任何结果更改都不会传播到从属。

REPAIR TABLE 存储引擎和分区支持

维修表适用于MyISAM 数据ARCHIVECSV表。对于MyISAM 数据表,默认情况下它与myisamchk --recover tblname具有相同的效果。此语句不适用于视图。

分区表支持维修表。但是,USE_FRM选项不能与分区 table 上的此语句一起使用。

您可以使用ALTER TABLE ... REPAIR PARTITION来修复一个或多个分区;有关更多信息,请参阅第 13.1.8 节,“ALTER TABLE 语法”第 22.3.4 节,“分区的维护”

REPAIR TABLE 选项

  • NO_WRITE_TO_BINLOGLOCAL

默认情况下,服务器将维修表 statements 写入二进制 log,以便它们复制到复制从属服务器。要禁止 logging,请指定可选的NO_WRITE_TO_BINLOG关键字或其别名LOCAL

  • QUICK

如果使用QUICK选项,则维修表尝试仅修复索引文件,而不是数据文件。这种类型的修复就像myisamchk --recover --quick那样。

  • EXTENDED

如果使用EXTENDED选项,MySQL 会逐行创建索引,而不是在 time 创建一个索引并进行排序。这种类型的修复就像myisamchk --safe-recover那样。

  • USE_FRM

如果.MYI索引文件丢失或其标头已损坏,则可以使用USE_FRM选项。此选项告诉 MySQL 不要信任.MYI文件头中的信息,并使用.frm文件中的信息来信任 re-create。使用myisamchk无法进行这种修复。

警告

仅当您不能使用常规REPAIR模式时才使用USE_FRM选项。告诉服务器忽略.MYI文件会使中存储的重要 table 元数据无法用于 repair process,这可能会产生有害后果:

  • 当前的AUTO_INCREMENT value 丢失了。

  • table 中已删除记录的链接将丢失,这意味着已删除记录的可用空间此后将保持未被占用状态。

  • .MYI标头指示 table 是否被压缩。如果服务器忽略此信息,则无法判断 table 是否已压缩,并且修复可能导致 table 内容的更改或丢失。这意味着USE_FRM不应与压缩表一起使用。无论如何,这应该是不必要的:压缩表是只读的,因此它们不应该被破坏。

如果你使用USE_FRM作为由 MySQL 服务器的不同 version 创建的 table 而不是你正在运行的 version,维修表不会尝试修复 table。在这种情况下,维修表返回的结果集包含一个值为errorMsg_text value 为Failed repairing incompatible .FRM file的 line。

如果使用USE_FRM,则维修表不检查 table 以查看是否需要升级。

REPAIR TABLE 输出

维修表返回结果集,其中包含以下 table 中显示的列。

Tabletable name
Op总是repair
Msg_typestatuserrorinfonotewarning
Msg_text信息性消息

维修表语句可能会为每个已修复的 table 生成许多行信息。最后一行的Msg_type value 为statusMsg_test通常应为OK。对于MyISAM table,如果你没有OK,你应该尝试用myisamchk --safe-recover修复它。 (维修表没有实现myisamchk的所有选项。使用myisamchk --safe-recover,您还可以使用维修表不支持的选项,例如--max-record-length .)

维修表 table 捕获并抛出将旧的损坏文件中的 table 统计信息复制到新创建的文件时发生的任何错误。例如。如果.frm.MYD.MYI文件的所有者的用户 ID 与mysqld process 的用户 ID 不同,则维修表生成“无法更改文件的所有权”错误,除非root用户启动mysqld

表修复注意事项

维修表升级 table 如果它包含 pre-5.6.4 格式的旧时间列(时间约会时间TIMESTAMP列而不支持小数秒精度)并禁用avoid_temporal_upgrade系统变量。如果启用avoid_temporal_upgrade,将忽略 table 中存在的旧时间列,并且不会升级它们。

要升级包含此类时间列的表,请在执行维修表之前禁用avoid_temporal_upgrade

您可以通过设置某些系统变量来增加维修表 performance。见第 8.6.3 节,“优化 REPAIR TABLE Statements”

Updated at: 9 months ago
OPTIMIZE TABLE 语法Table of content插件和 User-Defined Function Statements