You are here
Mysql - CHECK TABLE 语法
[转]Mysql - CHECK TABLE 语法
2013-11-13阅读201 评论0
CHECK TABLE 语法
CHECK TABLE tbl_name [, tbl_name] ... [option] ... option = {QUICK | FAST | MEDIUM | EXTENDED | CHANGED} |
用来检查表是否有错误。CHECK TABLE 对 GsSYS 和 GsDB 表有效。对于 GsSYS 表，键统计会被更新 。
CHECK TABLE 也可以检查视图中的问题，比如：视图定义中所参考的表已经不存在了。
CHECK TABLE 语句返回有如下列的一张表：
列 | 值 |
Table | 表名 |
Op | 分析 |
Msg_type | 状态，错误，信息或警告中的一个 |
Msg_text | 消息 |
 注意： |
| 该语句对于检查的表可能会产生多行信息。最后一行有一个状态的 Msg_type 值，Msg_text 通常为 OK。如果得到的不是 OK，通常要对其进行修复；是 OK 说明表已经是最新的了。表已经是最新的，意味着对这张表存储引擎不必进行检查。 |
下表列出了可供设置检查选项值。这些选项只适用于检查 GsSYS 表，对于 GsDB 表和视图将会被忽略。
类型 | 意义 |
QUICK | 不执行扫描行工作，进而也就不执行错误连接检查的工作。 |
FAST | 仅仅检查还没完全关闭的表。 |
CHANGED | 仅仅检查自从上次检查以来已经变化的表或还没关闭的表。 |
MEDIUM | 扫描行核实删除连接的正确性。这里也对行计算键校验和并且对校验和进行核实。 |
EXTENDED | 对每一行的所有键作完全键检查。这样确保了表 100% 一致，但是耗费时间! |
如果没有设定 QUICK, MEDIUM 或 EXTENDED 选项，对于动态格式 GsSYS 表缺省的检查类型是 MEDIUM。对于静态格式 GsSYS 表，如果没有设定 CHANGED 或 FAST，缺省检查类型也是 MEDIUM ，否则缺省为 QUICK。 对于 CHANGED 和 FAST ，会跳过行扫描，因为行通常很少被损坏。
可以组合使用这些选项，如下所示，对一张表进行快速检查以确定是否正确关闭了：
CHECK TABLE test_table FAST QUICK; |
| 注意： |
| 有时，CHECK TABLE 会修改表。如果一个表被标记为“损坏的” 或 “没有正确关闭”但 CHECK TABLE 在表中找不出任何问题，那么就会出现这种情况。这时 CHECK TABLE 把表标记为正常。 |
如果表被损坏了，很有可能问题出在索引中而不是在数据部分。前述的所有检查类型都会对索引进行彻底的检查，可以找出大多数的错误。
如果只打算检查用户假定是正常的表，应该不使用检查选项或使用 QUICK 选项。当时间紧迫而且可以承受很小的风险的时候，可以选用后者。因为 QUICK 不能找出数据文件中的错误，因而有一些很小的风险。(大多数情况下，在一般的用法中 GBase 应该找出数据文件中的错误。 如果在数据文件中发现了错误，那么这张表就会被标记为“损坏的”，在修复之前将不能使用。)
FAST 和 CHANGED 主要从脚本来使用 (例如,在定时执行工具 cron 中执行) ，如果想实时地对表进行检查。 大多数情况下，选 FAST 比 CHANGED 好。 (唯一的例外是当用户怀疑在 GsSYS 代码中已经发现了一个小错误。)
EXTENDED 只在下面的情况下使用：当 GBase 试图通过键来更新或查找一个行时，在运行了一个正常的检查之后但是还有奇怪的错误。 (如果一个正常的检查可以运行成功，那是不太可能出现这种情况的!)
一些 CHECK TABLE 所报的错是不能自动更正的：
- Found row where the auto_increment column has the value 0.
这表示表中有一行，该行的 AUTO_INCREMENT 索引列包含 0 值。(有可能在创建一行时，用 UPDATE 语句 AUTO_INCREMENT 列设成了0。)
它本身并不是一个错误，但在转储表和恢复表或对表进行 ALTER TABLERK 操作的时候会引起麻烦。在这种情况下，AUTO_INCREMENT 列按照 AUTO_INCREMENT 列规则改变它的值，这会导致诸如键重复的错误。
为了消除警告，在执行 UPDATE 语句的时候给这个列赋一个 0 以外的值。
来自 http://m.blog.csdn.net/blog/jichl/15791867