REPAIR [NO_WRITE_TO_BINLOG | LOCAL]
TABLE tbl_name [, tbl_name] ...
[QUICK] [EXTENDED] [USE_FRM]
修复表
修复可能损坏的表,对于某些存储引擎有效。
通常情况下,您不需要运行 修复表
,但是如果灾难发生,这个语句非常可能从 MyISAM
表中恢复所有数据。如果您的表经常损坏,请尝试找到原因,以消除使用 修复表
的需要。请参阅 第 B.3.3.3 节,“如果 MySQL Keeps Crashing” 和 第 18.2.4 节,“MyISAM 表问题”。
修复表
检查表以确定是否需要升级。如果需要,它将执行升级,遵循与 CHECK TABLE ... FOR UPGRADE
相同的规则。请参阅 第 15.7.3.2 节,“CHECK TABLE 语句”,以获取更多信息。
-
在执行表修复操作之前,请备份表;在某些情况下,操作可能会导致数据丢失。可能的原因包括但不限于文件系统错误。请参阅 第 9 章,《备份和恢复》。
-
如果服务器在执行
修复表
操作时退出,在重新启动服务器后,请立即执行另一个修复表
语句,以便在执行其他操作之前确保表的完整性。在最坏的情况下,您可能会获得一个新的干净索引文件,而没有数据文件信息,然后下一个操作可能会覆盖数据文件。这是一个不太可能但可能的情况,强调了备份的重要性。 -
如果源表变得损坏并且您在其上运行
修复表
,那么对原始表的任何更改都 不会 被传播到副本中。
修复表
适用于 MyISAM
、ARCHIVE
和 CSV
表。对于 MyISAM
表,它具有与 myisamchk --recover tbl_name
相同的效果。该语句不适用于视图。
修复表
支持分区表。然而,该语句不能在分区表上使用 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。Caution仅在无法使用常规
REPAIR
模式时使用USE_FRM
选项。告诉服务器忽略.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
返回一个结果集,包含以下表中的列。
Column | Value |
---|---|
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
升级表,如果它包含旧的时间列(TIME
、DATETIME
和TIMESTAMP
列)且avoid_temporal_upgrade
系统变量被禁用。如果avoid_temporal_upgrade
启用,REPAIR TABLE
忽略表中的旧时间列,不升级它们。
要升级包含这些时间列的表,禁用avoid_temporal_upgrade
,然后执行REPAIR TABLE
。
您可以通过设置某些系统变量来提高REPAIR TABLE
性能。请参阅第10.6.3节,“优化REPAIR TABLE语句”。