检查和维护MYSQL数据库表

理想的情况是，MySQL从首次安装以来始终平稳地运行。但有时确实会由于各种原因而出现问题，其范围可以从电源断电到硬件故障到不正常地关闭MySQL服务器（如用kill -9 终止服务器或机器崩溃）。诸如这样的情况大部分都超出您的控制范围，它们会导致数据库表的毁坏，尤其是在对表进行修改且未完全写入时所引起的。
    本章的重点是检测和解决表的问题，而不论问题是如何引起的。对于表的检查和修复，MySQL管理员最好的朋友是myisamchk 和isamchk 实用程序。这两个程序有好几个功能，我们已经在第4章讨论了怎样使用它们执行索引键的分布分析和索引的释放与激活。还可以使用它们检查表和修复有问题的表。这使您能在表变坏之前（使表不能使用之前）修正故障。
    myisamchk 和isamchk 提供的全部选项的清单在附录E 中。有关其他的背景，请参阅MySQL参考指南的“维护MySQL安装”一章。

    表的故障检测和修正的一般过程如下：
    1) 检查出错的表。如果该表检查通过，则完成任务，否则必须修复它。
    2) 在开始修复之前对表文件进行拷贝，以防万一。
    3) 试着修复表。
    4) 如果修复操作失败，从数据库备份和更新日志中恢复此表。
    上述过程的最后一步假定您已经执行了数据库备份并允许更新日志有效。如果不是这样的话，系统将有危险。参考第11章查找一下怎样使用mysqlaump 和怎样开启更新日志。您肯定不想不可挽回地丢失一个表，因此，应努力地做备份。
    在使用myisamchk 或isamchk 检查或修复表之前，应该满足一些初步需求：
    建立常规的数据库备份过程并允许更新日志，以防事情越来越糟使表的毁坏不能修复。笔者好像在以前提醒过这一点？
    在开始试验之前应先仔细地阅读本章的内容。尤其是不应该在阅读“避免与MySQL服务器交互作用”之前进行操作，因为它将讨论当您试图在一个表上执行检查或修复过程时服务器正在使用这个表所引起的问题。它还讨论怎样在服务器运行时防止那些问题发生。
    当运行表检查或修复时，您应该被注册在运行mysql的账号下，因为您需要对表文件读写访问。
   

myisamchk 和isamchk 的调用语法

    MySQL的myisamchk 和isamchk 实用程序很类似，多数时候它们可以用同样的方式使用。它们之间的主要区别是它们所使用的表的类型。对于MyISAM 表，使用my i s a m c h k，而对于ISAM 表，则使用i s a m c h k。您可以通过表的索引文件的扩展名来告诉表使用哪种存储格式。扩展名“. M Y I”表明是一个MyISAM 表，而“. I S M”表明是ISAM 表。
    为了使用任一个实用程序，应指明您所要检查或修复的表，以及指明要执行的操作类型的选项：
    % myisamchk options tbl_name...
    % isamchk options tbl_name...
    tbl_name 参数可以是表名也可以是该表的索引文件名。如果指定多个表，可以很容易地使用文件名模式来拾取目录中所有相应的文件：
    % myisamchk options *.MYI
    % isamchk options *.ISM
    不会因为告诉了错误的程序来检查某个表而使该表毁坏，但是除了发布一条警告消息外此程序不做任何事情。例如，下面的第一条语句将检查当前目录中的所有MyISAM 表，而第二条语句只显示一条警告消息：
    % myisamchk *.MYI 正确
    % myisamchk *.ISM 不正确─文件类型错
    不论是myisamchk 还是isamchk 都不对表所在的位置做任何判断，因此，应该或者在包含表文件的目录中运行程序，或者指定表的路径名。这允许您将表文件拷贝到另一个目录中并用该拷贝进行操作。

检查表

    myisamchk 和isamchk 提供了表检查方法，这些方法在彻底检查表的程度方面有差异。通常用标准方法就足够了。如果标准检查报告没有发现错误而您仍然怀疑有毁坏（或许因为查询没有正常地工作），可能要执行更彻底的检查。要想用任意一个实用程序执行标准的表检查，则不用带任何选项直接调用即可：
    % myisamchk tbl_name
    % isamchk tbl_name
    为了执行扩充检查，使用--extend-check 选项。该选项非常慢，但检查极为彻底。对于该表的数据文件中的每个记录，索引文件中的每个索引的相关键都被检查以确保它真正指向正确的记录。myisamchk 还有一个中间选项- - m e d i um - c h e c k，它不如扩展检查彻底，但速度快。
    如果对于--extend-check 检查不报告错误，则可以肯定表是好的。如果您仍然感觉表有问题，那原因肯定在其他地方。应重新检查任何好像有问题的查询以验证查询是正确书写的。如果您认为问题可能是MySQL服务器的原因，应考虑整理一份故障报告或升级到新的版本上。
    如果myisamchk 或isamchk 报告表有错误，应用下节中的说明修复它们。

修复表

    表的修复是一项可怕的工作，如果具体问题非常独特则更难进行。然而，有一些常规的指导思想和过程，可以遵循它们来增加修正表的机会。通常，开始时可以用最快的修复方法，看看是否能修正故障。如果发现不行的话，可以逐步升级到更彻底的（但更慢的）修复方法上，直到故障被修复或您不能继续升级为止（实际上，大多数问题不用更大规模的和更慢的方法就能修正）。如果表不能修复，则从备份中恢复该表。有关使用备份文件和更新日志进行恢复的指导在已第11章中给出。
    1. 执行标准的表修复
    为了修复一个表，执行下列步骤：
    1) 试着用--recover 选项修正表，但也可以用--quick 选项试图只根据索引文件的内容进行恢复。这样将不触及数据文件：
    % myisamchk --recover --quick tbl_name
    % isamchk --recover --quick tbl_name
    2) 如果问题仍存在，再试一下上一步的命令，但忽略--quick 选项，以允许my i s a m c h k或isamchk 前进并修改数据文件：
    % myisamchk --recover tbl_name
    % isamchk --recover tbl_name
    3) 如果还不工作，试一试--safe-recover 修复方法。这种方法比普通的恢复方法要慢，但能够修正-recover 方法不能修正的几个问题：
    % myisamchk --safe-recover tbl_name
    % isamchk --safe-recover tbl_name
    如果myisamchk 或isamchk 由于一个“C a n’t create new temp file: file_name” 的错误消息在任何一步中停止，应该重复这个命令并增加--force 选项以迫使清除临时文件。这个临时文件可能是从上一次失败的修复中留下的。
    在修复表之前拷贝它们在执行表修复前应该遵循的一个常规的预防措施是做该表的新拷贝。这种情况未必出现，但如果发生，则可以从拷贝文件中做该表的新的拷贝并试试另一种恢复方法。
    2. 标准表修复方法失败时怎么办
    如果标准的修复过程未能修复表，则索引文件可能在修复时丢失或毁坏。尽管未必可能，但还是有可能使表的描述文件丢失。不论哪种情况，都需要替换受影响的文件，然后再试试标准修复过程。
    为了重新生成索引文件，可以使用下列过程：
    1) 定位到包含崩溃表的数据库目录中。
    2) 将该表的数据文件移到安全的地方。
    3) 调用mysql并通过执行下列语句重新创建新的空表，该语句使用表的描述文件tbl_name.frm 重新开始生成新的数据和索引文件：
    mysql> DELETE FROM tbl_name;
    4) 退出mysql，将原始的数据文件移回到数据库目录中，替换刚建立的新的空文件。
    5) 再试试标准表修复方法。
    为了恢复该表的描述文件，可先从备份文件中恢复，然后再试着用标准修复方法。如果由于某些原因没有备份，但知道建立表的CREATE TABLE 语句，则仍可以恢复该文件：
    1) 定位到包含崩溃表的数据库目录中。
    2) 将该表的数据文件移动到安全的地方。如果想要使用索引的话，还需将索引文件移走。
    3) 调用mysql并发布CREATE TABLE 语句建立该表。
    4) 退出mysql，将原始数据文件移回数据库目录中，替换刚才新建的数据文件。如果在步骤2移动了索引文件，则也要将其移回数据库目录中。