MySQL中的CHECK TABLE语句和REPAIR TABLE语句

1>.CHECK TABLE语法

CHECK TABLE tbl_name[,tbl_name] ... [option] ...

option= {QUICK | FAST | MEDIUM | EXTENDED | CHANGED} 
 
检查一个或多个表是否有错误。CHECK TABLE对MyISAM和InnoDB表有作用。对于MyISAM表，关键字统计数据被更新。 
 CHECK TABLE也可以检查视图是否有错误，比如在视图定义中被引用的表已不存在。 
 CHECK TABLE语句会返回一个含有以下列的表：

列	值
Table	表名称
Op	进行检查
Msg_type	状态、错误、信息或错误之一
Msg_text	消息

 
注意，该语句可能会为每个被检查的表产生多行信息。最后一行有一个Msg_type状态值。Msg_text通常应为OK。如果您没有得到OK，或表已经更新了，则您通常应该运行修复后的表。请参见5.9.4节，“表维护和崩溃恢复”。表已经更新了，这意味着表的存储引擎指示没有必要检查表。 
可以给予的不同的检查选项列于下表中。这些选项只适用于检查MyISAM表。对于InnoDB表和视图，这些选项被忽略。

类型	意义
QUICK	不扫描行，不检查错误的链接。
FAST	只检查没有被正确关闭的表。
CHANGED	只检查上次检查后被更改的表，和没有被正确关闭的表。
MEDIUM	扫描行，以验证被删除的链接是有效的。也可以计算各行的关键字校验和，并使用计算出的校验和验证这一点。
EXTENDED	对每行的所有关键字进行一个全面的关键字查找。这可以确保表是100％一致的，但是花的时间较长。

 
如果没有指定QUICK, MEDIUM或EXTENDED选项，则对于动态格式MyISAM表，默认检查类型是MEDIUM。这与对表运行myisamchk --medium-checktbl_name的结果相同。对于静态格式MyISAM表，默认检查类型也是MEDIUM，除非CHANGED或FAST已被指定。在此情况下，默认值为QUICK。对于CHANGED和FAST，行扫描被跳过，因为行极少被破坏。 
您可以组合检查选项，如下面的例子所示。该例子对表进行了一个快速检查，来查看该表是否被正确关闭：

CHECK TABLE test_table FAST QUICK; 

 
注释：在有些情况下，CHECK TABLE会更改表。如果表被标记为“corrupted”或“not closed properly”，则出现这种情况。但是CHECK TABLE不会找出表中的问题。在这种情况下，CHECK TABLE会把表标记为良好。 
如果一个表被破坏，很有可能问题在索引中，而不在数据部分中。所有前述的检查类型都可以彻底地检查索引，因此，可以找出多数的错误。 
如果您只想要检查您假定的表是良好的，您应该不使用检查选项或QUICK选项。当您时间匆忙时，应使用QUICK。QUICK无法找出数据文件中的错误的风险非常小。（在多数情况下，在正常使用中，MySQL应能在数据文件中找出错误。如果找出了错误，表被标记为“corrupted”，并不能被使用，直到修复为止。） 
如果您想要时常检查表，FAST和CHANGED多数情况下从原本中被使用（例如，从cron中被执行）。在多数情况下，FAST优先于CHANGED。（只有一种情况FAST不优先于CHANGED，那就是当您怀疑您在MyISAM代码中发现了错误。） 
当MySQL试图通过关键字更新一行或查找一行时，如果您已经运行了一个常规检查后但仍得到来自表的奇怪的错误，此时使用EXTENDED。（如果常规的检查运行成功，则基本用不着EXTENDED。） 
被CHECK TABLE报告的部分问题不会被自动修正： 
 ?        发现行。此行中，auto_increment列有0值。 
这意味着，您在表中有一行，该行的AUTO_INCREMENT索引列包含0值。（可以通过使用UPDATE语句，明确地把列设置为0，以创建一个AUTO_INCREMENT列为0的行。） 
这本身不是一个错误，但是如果您决定转储表并恢复表，或对表进行ALTER TABLE，那么会导致出现麻烦。在此情况下，AUTO_INCREMENT列会根据AUTO_INCREMENT列的结果更改值，这会导致出现问题，如重复关键字错误等。 
要消除警告，只需执行一个UPDATE语句，把列设置为除0以外的值。

2>.REPAIR TABLE的用法： 

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

REPAIR TABLE用于修复被破坏的表。默认情况下，REPAIR TABLE与myisamchk --recover tbl_name具有相同的效果。REPAIR TABLE对MyISAM和ARCHIVE表起作用。

通常，您基本上不必运行此语句。但是，如果灾难发生，REPAIR TABLE很有可能从MyISAM表中找回所有数据。如果您的表经常被破坏，您应该尽力找到原因，以避免使用REPAIR TALBE。

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

列	值
Table	表名称
Op	进行修复
Msg_type	状态、错误、信息或警告之一
Msg_text	消息

对于每个被修复的表，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语句。（通过制作一个备份来启动是一个好办法。）再最不利情况下，您可以有一个新的干净的索引文件，不含有关数据文件的信息。然后，您执行的下一个操作会覆盖数据文件。这很少发生，但是是有可能的。