7.6.3 如何修复 MyISAMtable

本节中的讨论描述了如何在MyISAM个 table(extensions.MYI和.MYD)上使用myisamchk。

您还可以使用CHECK TABLE和REPAIR TABLE语句检查和修复MyISAMtable。参见第 13.7.2.2 节“ CHECK TABLE 语句”和第 13.7.2.5 节“ REPAIR TABLE 语句”。

损坏的 table 的症状包括查询意外中止和可观察到的错误，例如：

• tbl_name.frm禁止更改

• 找不到文件tbl_name.MYI(错误代码：* nnn *)

• 文件意外结束

• 记录文件已崩溃

• table 处理程序出现错误* nnn *

要获取有关该错误的更多信息，请运行perror * nnn ，其中 nnn *是错误号。下面的示例说明如何使用perror查找最常见的错误编号的含义，这些错误编号 table 明 table 存在问题：

shell> perror 126 127 132 134 135 136 141 144 145
MySQL error code 126 = Index file is crashed
MySQL error code 127 = Record-file is crashed
MySQL error code 132 = Old database file
MySQL error code 134 = Record was already deleted (or record file crashed)
MySQL error code 135 = No more room in record file
MySQL error code 136 = No more room in index file
MySQL error code 141 = Duplicate unique key or constraint on write or update
MySQL error code 144 = Table is crashed and last repair failed
MySQL error code 145 = Table was marked as crashed and should be repaired

请注意，错误 135(记录文件中没有更多空间)和错误 136(索引文件中没有更多空间)不是可以通过简单修复即可解决的错误。在这种情况下，您必须使用ALTER TABLE来增加MAX_ROWS和AVG_ROW_LENGTHtable 选项的值：

ALTER TABLE tbl_name MAX_ROWS=xxx AVG_ROW_LENGTH=yyy;

如果您不知道当前 table 选项的值，请使用显示创建 table。

对于其他错误，您必须修复 table。 myisamchk通常可以检测并修复大多数发生的问题。

维修过程涉及四个阶段，在此介绍。在开始之前，您应该将位置更改为数据库目录，并检查 table 文件的权限。在 Unix 上，请确保mysqld的运行用户(以及您自己，因为您需要访问要检查的文件)可以读取它们。如果事实证明您需要修改文件，那么它们也必须是可写的。

本节适用于 table 检查失败的情况(例如第 7.6.2 节“如何检查 MyISAMtable 中的错误”中描述的情况)，或者您要使用myisamchk提供的扩展功能。

第 4.6.3 节“ myisamchk-MyISAMtable 维护 Util”中描述了用于 table 维护的myisamchk选项。 myisamchk还具有可以设置为控制内存分配的变量，可以提高性能。参见第 4.6.3.6 节“ myisamchk 内存使用情况”。

如果要从命令行修复 table，则必须首先停止mysqld服务器。请注意，在远程服务器上执行mysqladmin shutdown时，在mysqladmin返回之后mysqld服务器仍然可以使用一段时间，直到所有语句处理停止并且所有索引更改都已刷新到磁盘上为止。

阶段 1：检查您的桌子

如果有更多时间，请运行myisamchk *.MYI或myisamchk -e * .MYI。使用-s(静默)选项可禁止显示不必要的信息。

如果mysqld服务器已停止，则应使用--update-state选项告诉myisamchk将 table 标记为“已选中”。

您只需要修复myisamchk宣布错误的 table。对于此类 table，请转到阶段 2.

如果在检查时遇到意外错误(例如out of memory错误)或myisamchk崩溃，请转到阶段 3.

第二阶段：轻松安全维修

首先，尝试myisamchk -r -q tbl_name(-r -qtable 示“快速恢复模式”)。这将尝试修复索引文件而不接触数据文件。如果数据文件包含应有的所有内容，并且删除链接指向数据文件中的正确位置，则该文件应该起作用，并且 table 已修复。开始修复下 table。否则，请使用以下过程：

• 在 continue 操作之前，请备份数据文件。

• 使用myisamchk -r tbl_name(-rtable 示“恢复模式”)。这将从数据文件中删除不正确的行和已删除的行，并重建索引文件。

• 如果上一步失败，请使用myisamchk-安全恢复 tbl_name。安全恢复模式使用一种旧的恢复方法，该方法可以处理一些常规恢复模式无法解决的问题(但速度较慢)。

如果您在修复时遇到意外错误(例如out of memory错误)，或者myisamchk崩溃，请转到阶段 3.

阶段 3：难以维修

仅当索引文件中的前 16KB 块被破坏或包含不正确的信息，或者缺少索引文件时，才应进入此阶段。在这种情况下，有必要创建一个新的索引文件。这样做如下：

• 将数据文件移到安全的地方。

• 使用 table 描述文件来创建新的(空)数据和索引文件：

shell> mysql db_name

mysql> SET autocommit=1;
mysql> TRUNCATE TABLE tbl_name;
mysql> quit

• 将旧数据文件复制回新创建的数据文件。 (不要只是将旧文件移回新文件.您要保留副本，以防出现问题.)

返回到阶段 2.myisamchk -r -q应该起作用。 (这不应是一个无限循环.)

您还可以使用REPAIR TABLE tbl_name USE_FRM SQL 语句，该语句自动执行整个过程。Util 和服务器之间也不会发生不必要的交互，因为当您使用REPAIR TABLE时，服务器会完成所有工作。参见第 13.7.2.5 节“ REPAIR TABLE 语句”。

阶段 4：维修非常困难

仅当.frm说明文件也崩溃时，您才应该进入此阶段。这永远不会发生，因为创建 table 后描述文件不会更改：

• 从备份还原描述文件并返回到阶段 3.您还可以还原索引文件并回到阶段 2.在后一种情况下，您应该以myisamchk -r开头。

• 如果您没有备份，但确切知道该 table 是如何创建的，请在另一个数据库中创建该 table 的副本。删除新的数据文件，然后将.frm描述文件和.MYI索引文件从另一个数据库移至崩溃的数据库。这为您提供了新的描述文件和索引文件，但.MYD数据文件不存在。返回到阶段 2 并尝试重建索引文件。