随笔 - 39  文章 - 1  trackbacks - 0
<2013年9月>
25262728293031
1234567
891011121314
15161718192021
22232425262728
293012345

常用链接

留言簿

随笔档案

搜索

  •  

最新评论

阅读排行榜

评论排行榜

  [pre]REPAIR [LOCAL | NO_WRITE_TO_BINLOG] TABLE[/pre][pre] tbl_name[,tbl_name] … [QUICK] [EXTENDED] [USE_FRM][/pre]REPAIR TABLE用于修复被破坏的表。默认情况下,REPAIR TABLE与myisamchk --recovertbl_name具有相同的效果。REPAIR TABLE对MyISAM和ARCHIVE表起作用。oracle培训

  通常,您基本上不必运行此语句。但是,如果灾难发生,REPAIR TABLE很有可能从MyISAM表中找回所有数据。如果您的表经常被破坏,您应该尽力找到原因,以避免使用REPAIR TALBE。请参见A.4.2节,“如果MySQL依然崩溃,应作些什么”。同时也见15.1.4节,“MyISAM表方面的问题”。

  本语句会返回一个含有以下列的表:

MySQL数据库中的REPAIRTABLE语法介绍

  对于每个被修复的表,REPAIR TABLE语句会产生多行的信息。上一行含有一个Msg_type状态值。Msg_test通常应为OK。如果您没有得到OK,您应该尝试使用myisamchk --safe-recover修复表,因为REPAIR TABLE尚不会执行所有的myisamchk选项。我们计划在将来使它的灵活性更强。

  如果给定了QUICK,则REPAIR TABLE会尝试只修复索引树。这种类型的修复与使用myisamchk --recover --quick相似。

  如果您使用EXTENDED,则MySQL会一行一行地创建索引行,代替使用分类一次创建一个索引。这种类型的修复与使用myisamchk --safe-recover相似。

  对于REPAIR TABLE,还有一种USE_FRM模式可以利用。如果。MYI索引文件缺失或标题被破坏,则使用此模式。在这种模式下,MySQL可以使用来自。frm文件重新创建。MYI文件。这种修复不能使用myisamchk来完成。 注释:只能在您不能使用常规REPAIR模式是,才能使用此模式。。MYI标题包含重要的表元数据(特别是,当前的AUTO_INCREMENT值和Delete链接)。这些元数据在REPAIR…USE_FRM中丢失。如果表被压缩,则不能使用USE_FRM。因为本信息也存储在。MYI文件中。

  REPAIR TABLE语句被写入二进制日志中,除非使用了自选的NO_WRITE_TO_BINLOG关键词(或其别名LOCAL)。

  警告:如果在REPAIR TABLE运行过程中,服务器停机,则在重新启动之后,在执行其它操作之前,您必须立刻对表再执行一个REPAIR TABLE语句。(通过制作一个备份来启动是一个好办法。)再最不利情况下,您可以有一个新的干净的索引文件,不含有关数据文件的信息。然后,您执行的下一个操作会覆盖数据文件。这很少发生,但是是有可能的。

posted on 2013-09-04 14:05 亲爱的小孩 阅读(187) 评论(0)  编辑  收藏

只有注册用户登录后才能发表评论。


网站导航: