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继续崩溃,该怎么办”和“ MyISAM表问题”。
REPAIR TABLE
检查表以参见是否需要升级。如果是这样,它将按照与相同的规则执行升级CHECK TABLE ... FOR UPGRADE
。有关更多信息,请参见“ CHECK TABLE语句”。
重要
- 在执行表修复操作之前,请备份表;在某些情况下,该操作可能会导致数据丢失。可能的原因包括但不限于文件系统错误。请参阅备份和恢复。
- 如果服务器在
REPAIR TABLE
操作过程中崩溃,则在重新启动服务器后必须立即REPAIR TABLE
对表执行另一条语句,然后再对其执行任何其他操作。在最坏的情况下,您可能有一个新的干净索引文件,而没有有关数据文件的信息,然后执行的下一个操作可能会覆盖数据文件。这是不太可能但可能的情况,强调了首先进行备份的价值。- 如果主服务器上的表损坏并
REPAIR TABLE
在其上运行,则对原始表所做的任何更改都不会传播到从属服务器。
- 维修表存储引擎和分区支持
- 维修台选项
- 维修台输出
- 表维修注意事项
维修表存储引擎和分区支持
REPAIR TABLE
工程MyISAM
,ARCHIVE
和CSV
表。对于MyISAM
表,默认情况下它与myisamchk --recover tbl_name
具有相同的效果。该语句不适用于视图。
REPAIR TABLE
支持分区表。但是,该USE_FRM
选项不能与分区表上的该语句一起使用。
您可以ALTER TABLE ... REPAIR PARTITION
用来修复一个或多个分区。有关更多信息,请参见“ ALTER TABLE语句”和“分区的维护”。
维修台选项
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
通过设置某些系统变量来提高性能。请参见“REPAIR TABLE 语句(优化)”。