为了有用，必须定期安排备份。 可以使用多种工具在MySQL中完成完整备份（某个时间点的数据快照）。 例如， MySQL Enterprise Backup 可以执行 整个实例 的 物理备份 ，通过优化来最小化开销并避免在备份 InnoDB 数据文件 时中断 ; mysqldump 提供在线 逻辑备份 。 本讨论使用 mysqldump 。

假设我们 InnoDB 在周日下午1点使用以下命令对所有数据库中 的所有 表 进行完整备份 ，当负载较低时：

外壳> mysqldump --all-databases --master-data --single-transaction > backup_sunday_1_PM.sql

mysqldump 生成的结果 .sql 文件 包含一组SQL 语句，可用于稍后重新加载转储的表。 INSERT

此备份操作在转储开始时（使用 FLUSH TABLES WITH READ LOCK ） 获取所有表的全局读锁定 。 获取此锁定后，将读取二进制日志坐标并释放锁定。 如果在 FLUSH 发出 语句时正在运行长更新语句 ，则备份操作可能会停止，直到这些语句完成。 之后，转储变得无锁，并且不会干扰表上的读取和写入。

之前假设要备份的表是 InnoDB 表，因此 --single-transaction 使用一致的读取并保证 mysqldump 看到的数据 不会更改。 （ mysqldump 进程 InnoDB 看不到 其他客户端对 表 所做的更改 。）如果备份操作包括非事务性表，则一致性要求它们在备份期间不会更改。 例如，对于 数据库中 的 表， 备份期间不得对MySQL帐户进行任何管理更改。 MyISAM mysql

完整备份是必要的，但创建它们并不总是方便。 它们生成大型备份文件并花费时间生成。 它们并不是最佳的，因为每个连续的完整备份都包含所有数据，即使是自上次完全备份以来未发生更改的部分。 进行初始完整备份然后进行增量备份更有效。 增量备份更小，生成时间更短。 权衡是，在恢复时，只能通过重新加载完整备份来恢复数据。 您还必须处理增量备份以恢复增量更改。

要进行增量备份，我们需要保存增量更改。 在MySQL中，这些更改在二进制日志中表示，因此应始终使用 --log-bin 启用该日志 的 选项 启动MySQL服务器 。 启用二进制日志记录后，服务器会在更新数据时将每个数据更改写入文件。 查看使用该 --log-bin 选项 启动 并且已运行了几天 的MySQL服务器的数据目录 ，我们找到这些MySQL二进制日志文件：

-rw-rw ---- 1 guilhem guilhem 1277324 11月10日23:59 gbichot2-bin.000001
-rw-rw ---- 1 guilhem guilhem 4月10日23:59 gbichot2-bin.000002
-rw-rw ---- 1 guilhem guilhem 79 Nov 11 11:06 gbichot2-bin.000003
-rw-rw ---- 1 guilhem guilhem 508 Nov 11 11:08 gbichot2-bin.000004
-rw-rw ---- 1 guilhem guilhem 220047446 11月12日16:47 gbichot2-bin.000005
-rw-rw ---- 1 guilhem guilhem 998412 11月14日10:08 gbichot2-bin.000006
-rw-rw ---- 1 guilhem guilhem 361 Nov 14 10:07 gbichot2-bin.index

每次重新启动时，MySQL服务器都会使用序列中的下一个数字创建一个新的二进制日志文件。 在服务器运行时，您还可以通过发出 FLUSH LOGS SQL语句或使用 mysqladmin flush-logs 命令 告诉它关闭当前的二进制日志文件并手动开始新的日志文件 。 mysqldump 还有一个刷新日志的选项。 该 .index 数据目录文件中包含该目录下所有MySQL二进制日志的清单。

MySQL二进制日志对于恢复非常重要，因为它们构成了一组增量备份。 如果确保在进行完全备份时刷新日志，则之后创建的二进制日志文件将包含自备份以来所做的所有数据更改。 让我们 稍微 修改之前的 mysqldump 命令，以便在完全备份时冲洗MySQL二进制日志，以便转储文件包含新的当前二进制日志的名称：

外壳> mysqldump --single-transaction --flush-logs --master-data=2 \
         --all-databases > backup_sunday_1_PM.sql

执行此命令后，数据目录包含新的二进制日志文件 gbichot2-bin.000007 ，因为该 --flush-logs 选项会导致服务器刷新其日志。 该 --master-data 选项导致 mysqldump 将二进制日志信息写入其输出，因此生成的 .sql 转储文件包括以下行：

- 从中​​开始复制或时间点恢复的位置
-  CHANGE MASTER TO MASTER_LOG_FILE ='gbichot2-bin.000007'，MASTER_LOG_POS = 4;

因为 mysqldump 命令进行了完整备份，所以这些行意味着两件事：

在星期一下午1点，我们可以通过刷新日志来开始新的二进制日志文件来创建增量备份。 例如，执行 mysqladmin flush-logs 命令会创建 gbichot2-bin.000008 。 周日下午1点完整备份和周一下午1点之间的所有更改都将在 gbichot2-bin.000007 文件中。 此增量备份很重要，因此最好将其复制到安全的地方。 （例如，将其备份到磁带或DVD上，或将其复制到另一台计算机上。）在星期二下午1点，执行另一个 mysqladmin flush-logs 命令。 周一下午1点到周二下午1点之间的所有更改都将在 gbichot2-bin.000008 文件中（也应该在安全的地方复制）。

MySQL二进制日志占用磁盘空间。 为了腾出空间，不时清除它们。 一种方法是删除不再需要的二进制日志，例如当我们进行完整备份时：

外壳> mysqldump --single-transaction --flush-logs --master-data=2 \
         --all-databases --delete-master-logs > backup_sunday_1_PM.sql

现在，假设我们在星期三上午8点发生了灾难性的崩溃，需要从备份中恢复。 要恢复，首先我们恢复上一次完整备份（从星期日下午1点开始）。 完整备份文件只是一组SQL语句，因此恢复它非常简单：

外壳> mysql < backup_sunday_1_PM.sql

此时，数据将恢复到截至周日下午1点的状态。 要恢复自那时以来所做的更改，我们必须使用增量备份; 也就是 gbichot2-bin.000007 和 gbichot2-bin.000008 二进制日志文件。 必要时从备份位置获取文件，然后按如下方式处理其内容：

外壳> mysqlbinlog gbichot2-bin.000007 gbichot2-bin.000008 | mysql

我们现在已经将数据恢复到周二下午1点的状态，但仍然缺少从该日期到崩溃日期的更改。 为了不丢失它们，我们需要让MySQL服务器将其MySQL二进制日志存储到与存储其数据文件的地方不同的安全位置（RAID磁盘，SAN，...），以便这些日志不会在被破坏的磁盘上。 （也就是说，我们可以使用一个 --log-bin 选项 来启动服务器，该 选项指定与数据目录所在的物理设备不同的物理设备上的位置。这样，即使包含该目录的设备丢失，日志也是安全的。）如果我们做到了这一点，我们会有 gbichot2-bin.000009 手头的文件（以及任何后续文件），我们可以使用 mysqlbinlog 和 mysql 来 应用它们 来恢复最新的数据更改，直到崩溃时都没有损失：

外壳> mysqlbinlog gbichot2-bin.000009 ... | mysql

有关使用 mysqlbinlog 处理二进制日志文件的 更多信息 ，请参见 第7.5节“使用二进制日志进行时间点（增量）恢复” 。

如果操作系统崩溃或电源故障， InnoDB 它本身会完成恢复数据的所有工作。 但为了确保您能够安然入睡，请遵守以下准则：

本节介绍如何使用 mysqldump 创建SQL格式转储文件。 有关重新加载此类转储文件的信息，请参见 第7.4.2节“重新加载SQL格式备份” 。

默认情况下， mysqldump 将信息作为SQL语句写入标准输出。 您可以将输出保存在文件中：

外壳> mysqldump [arguments] > file_name

要转储所有数据库，请 使用以下 选项 调用 mysqldump --all-databases ：

外壳> mysqldump --all-databases > dump.sql

要仅转储特定数据库，请在命令行中为它们命名并使用以下 --databases 选项：

外壳> mysqldump --databases db1 db2 db3 > dump.sql

该 --databases 选项使命令行上的所有名称都被视为数据库名称。 如果没有此选项， mysqldump 会将第一个名称视为数据库名称，将后续名称视为表名称。

使用 --all-databases or --databases ， mysqldump 在每个数据库的转储输出之前 写入 CREATE DATABASE 和 USE 语句。 这可确保在重新加载转储文件时，如果每个数据库不存在，它将创建每个数据库，并使其成为默认数据库，以便将数据库内容加载到它们所来自的同一数据库中。 如果要在重新创建数据库之前使转储文件强制删除每个数据库，请同时使用该 --add-drop-database 选项。 在这种情况下， mysqldump 在 DROP DATABASE 每个 CREATE DATABASE 语句 之前 写一个 语句。

要转储单个数据库，请在命令行中为其命名：

外壳> mysqldump --databases test > dump.sql

在单数据库的情况下，允许省略 --databases 选项：

外壳> mysqldump test > dump.sql

前面两个命令之间的区别在于，没有 --databases ，转储输出包含no CREATE DATABASE 或 USE 语句。 这有几个含义：

要仅从数据库转储特定表，请在数据库名称后面的命令行中为它们命名：

外壳> mysqldump test t1 t3 t7 > dump.sql

要重新加载由 mysqldump 编写的 包含SQL语句 的转储文件 ，请将其用作 mysql 客户端的 输入 。 如果转储文件是由 mysqldump 使用 --all-databases or --databases 选项 创建的 ，则它包含 CREATE DATABASE 和 USE 语句，并且没有必要指定要加载数据的默认数据库：

外壳> mysql < dump.sql

或者，从 mysql中 ，使用 source 命令：

MySQL的> source dump.sql

如果文件是不包含 CREATE DATABASE 和 USE 语句 的单数据库转储 ，请首先创建数据库（如有必要）：

外壳> mysqladmin create db1

然后在加载转储文件时指定数据库名称：

外壳> mysql db1 < dump.sql

或者，在 mysql 中创建数据库，将其选为默认数据库，然后加载转储文件：

mysql> CREATE DATABASE IF NOT EXISTS db1;
mysql> USE db1;
mysql>source dump.sql

本节介绍如何使用 mysqldump 创建分隔文本转储文件。 有关重新加载此类转储文件的信息，请参见 第7.4.4节“重新加载分隔文本格式备份” 。

如果 使用该 选项 调用 mysqldump ，它将 用作输出目录，并使用每个表的两个文件在该目录中单独转储表。 表名是这些文件的基本名称。 对于名为的表 ，文件名为 and 。 该 文件包含 该表 的 语句。 该 文件包含表数据，每个表行一行。 --tab=dir_name dir_name t1 t1.sql t1.txt .sql CREATE TABLE .txt

以下命令将 db1 数据库 的内容转储到 数据库中的文件 /tmp ：

外壳> mysqldump --tab=/tmp db1

.txt 包含表数据 的 文件由服务器写入，因此它们由用于运行服务器的系统帐户拥有。 服务器用于 SELECT ... INTO OUTFILE 写入文件，因此您必须具有 FILE 执行此操作 的 权限，并且如果给定 .txt 文件已存在 则会发生错误 。

服务器将 CREATE 转储表 的 定义 发送 到 mysqldump ，后者将它们写入 .sql 文件。 因此，这些文件由执行 mysqldump 的用户拥有 。

最好 --tab 只用于转储本地服务器。 如果您与远程服务器使用，该 --tab 目录必须存在于本地和远程主机都和 .txt 文件将通过在远程目录服务器（服务器主机上）写，而 .sql 文件将被写入 的mysqldump 在本地目录（在客户端主机上）。

对于 mysqldump --tab ，服务器默认情况下将表数据写入 .txt 文件每行一行，列值之间有选项卡，列值周围没有引号，新行作为行终止符。 （这些默认值与 SELECT ... INTO OUTFILE 。 相同 。）

要使用不同的格式写入数据文件， mysqldump 支持以下选项：

根据您为任何这些选项指定的值，可能需要在命令行上为命令解释程序引用或转义值。 或者，使用十六进制表示法指定值。 假设您希望 mysqldump 在双引号内引用列值。 为此，请指定双引号作为 --fields-enclosed-by 选项 的值 。 但是这个角色通常对指挥口译员来说是特殊的，必须特别对待。 例如，在Unix上，您可以引用双引号，如下所示：

--fields封闭逐=““”

在任何平台上，您都可以以十六进制指定值：

--fields封闭逐=为0x22

通常一起使用几个数据格式化选项。 例如，要以逗号分隔值格式转储表格，并使用由回车符/换行符对（ \r\n ） 终止的行 ，请使用此命令（在一行中输入）：

外壳> mysqldump --tab=/tmp --fields-terminated-by=,
         --fields-enclosed-by='"' --lines-terminated-by=0x0d0a db1

如果您使用任何数据格式化选项来转储表数据，则需要在以后重新加载数据文件时指定相同的格式，以确保正确解释文件内容。

对于使用 mysqldump生成的 备份 --tab ，每个表在输出目录中由 .sql 包含 CREATE TABLE 表 的 语句的 .txt 文件 和 包含表数据 的 文件表示。 要重新加载表，首先将位置更改为输出目录。 然后 .sql 使用 mysql 处理 文件 以创建一个空表并处理该 .txt 文件以将数据加载到表中：

shell> mysql db1 < t1.sql
shell>mysqlimport db1 t1.txt

使用 mysqlimport 加载数据文件 的另一种方法 是使用 mysql 客户端中 的 LOAD DATA 语句 ：

mysql> USE db1;
mysql>LOAD DATA INFILE 't1.txt' INTO TABLE t1;

如果 在最初转储表时 使用了 mysqldump的 任何数据格式化选项 ，则必须使用与 mysqlimport 相同的选项 或 LOAD DATA 确保正确解释数据文件内容：

外壳> mysqlimport --fields-terminated-by=,
         --fields-enclosed-by='"' --lines-terminated-by=0x0d0a db1 t1.txt

要么：

mysql> USE db1;
mysql>LOAD DATA INFILE 't1.txt' INTO TABLE t1
       FIELDS TERMINATED BY ',' FIELDS ENCLOSED BY '"'
       LINES TERMINATED BY '\r\n';

本节介绍了使用 mysqldump 解决特定问题的技术：

shell> mysqldump db1 > dump.sql
shell> mysqladmin create db2
shell>mysql db2 < dump.sql

外壳> mysqldump --databases db1 > dump.sql

外壳> mysql < dump.sql

外壳> mysqldump db1 > dump.sql

shell> mysqladmin create db1
shell>mysql db1 < dump.sql

shell> mysqldump --no-data test > dump-defs.sql
shell>mysqldump --no-create-info test > dump-data.sql

外壳> mysqldump --no-data --routines --events test > dump-defs.sql

外壳> mysqldump --all-databases --no-data --routines --events > dump-defs.sql

外壳> mysql < dump-defs.sql

外壳> mysqldump --all-databases --no-create-info > dump-data.sql

外壳> mysql < dump-data.sql

要指示恢复的开始和结束时间 ，请以 格式 指定 mysqlbinlog 的 --start-datetime 和 --stop-datetime 选项 。 例如，假设确切地在2005年4月20日上午10:00执行了删除大表的SQL语句。 要还原表和数据，可以还原前一晚的备份，然后执行以下命令： DATETIME

外壳> mysqlbinlog --stop-datetime="2005-04-20 9:59:59" \
         /var/log/mysql/bin.123456 | mysql -u root -p

此命令将恢复所有数据，直到该 --stop-datetime 选项 给出的日期和时间 。 如果您没有检测到几小时后输入的错误SQL语句，您可能还希望恢复之后发生的活动。 基于此，您可以 使用开始日期和时间再次 运行 mysqlbinlog ，如下所示：

外壳> mysqlbinlog --start-datetime="2005-04-20 10:01:00" \
         /var/log/mysql/bin.123456 | mysql -u root -p

在此命令中，将重新执行从上午10:01开始记录的SQL语句。 恢复前一晚的转储文件和两个 mysqlbinlog 命令的组合将所有内容恢复到上午10:00之前的一秒钟以及从上午10:01开始的所有内容。

要使用此时间点恢复方法，您应检查日志以确保为命令指定的确切时间。 要显示日志文件内容而不执行它们，请使用以下命令：

外壳> mysqlbinlog /var/log/mysql/bin.123456 > /tmp/mysql_restore.sql

然后 /tmp/mysql_restore.sql 使用文本编辑器 打开 文件进行检查。

如果多个语句与要排除的语句同时执行，则 通过指定 mysqlbinlog的 时间来排除特定更改将 无法正常工作。

mysqlbinlog 的 --start-position 和 --stop-position 选项 可用于指定日志位置 ，而不是指定日期和时间 。 除了指定日志位置编号而不是日期之外，它们的工作方式与启动和停止日期选项相同。 使用位置可以使您更准确地了解要恢复的日志部分，尤其是在许多事务与破坏性SQL语句同时发生的情况下。 要确定位置编号，请 在执行不需要的事务的时间附近 运行 mysqlbinlog 一段时间，但将结果重定向到文本文件以供检查。 这可以这样做：

外壳> mysqlbinlog --start-datetime="2005-04-20 9:55:00" \
         --stop-datetime="2005-04-20 10:05:00" \
         /var/log/mysql/bin.123456 > /tmp/mysql_restore.sql

此命令在 /tmp 目录中 创建一个小文本文件，该 文件包含执行有害SQL语句时的SQL语句。 使用文本编辑器打开此文件，然后查找您不想重复的语句。 确定二进制日志中的位置以停止和恢复恢复并记下它们。 职位标记为 log_pos 后跟数字。 恢复上一个备份文件后，使用位置编号处理二进制日志文件。 例如，您将使用以下命令：

外壳> mysqlbinlog --stop-position=368312 /var/log/mysql/bin.123456 \
         | mysql -u root -p

外壳> mysqlbinlog --start-position=368315 /var/log/mysql/bin.123456 \
         | mysql -u root -p

第一个命令恢复所有事务，直到给出停止位置。 第二个命令恢复从给定的起始位置到二进制日志结束的所有事务。 因为 mysqlbinlog 的输出 包括 SET TIMESTAMP 记录每个SQL语句之前的语句，所以恢复的数据和相关的MySQL日志将反映执行事务的原始时间。

本节介绍如何检查和处理MySQL数据库中的数据损坏。 如果您的表经常损坏，您应该尝试找出原因。 请参见 第B.4.3.3节“如果MySQL不断崩溃该怎么办” 。

有关 MyISAM 表 如何 损坏的说明，请参见 第16.2.4节“MyISAM表问题” 。

如果运行 mysqld 并禁用外部锁定（这是默认设置），则 当 mysqld 使用同 一个表时 ，您无法可靠地使用 myisamchk 检查 表。 如果你可以确定在 运行 myisamchk 时 没有人会通过 mysqld 访问表 ，你只需要 在开始检查 表 之前 执行 mysqladmin flush- tables。 如果你不能保证这一点，你必须 在检查表时 停止 mysqld 。 如果你运行 myisamchk 来检查 mysqld的 表 在同时更新时，您可能会收到一个警告，即表格已损坏，即使它没有。

如果在启用外部锁定的情况下运行服务器，则可以随时使用 myisamchk 检查表。 在这种情况下，如果服务器尝试更新 myisamchk 正在使用 的表， 服务器将等待 myisamchk 完成后再继续。

如果使用 myisamchk 来修复或优化表，则 必须 始终确保 mysqld 服务器未使用该表（如果禁用外部锁定，这也适用）。 如果你不停止 mysqld ，你至少应该在 运行 myisamchk 之前 做一个 mysqladmin flush-tables 。 如果服务器和 myisamchk 同时访问表， 您的表 可能会损坏 。

执行崩溃恢复时，请务必了解 数据库 中的每个 MyISAM 表 tbl_name 都对应于下表中显示的数据库目录中的三个文件。

这三种文件类型中的每一种都以各种方式受到损坏，但数据文件和索引文件中最常出现问题。

myisamchk的 工作原理是 .MYD 逐行 创建 数据文件 的副本 。 它通过删除旧 .MYD 文件并将新文件重命名为原始文件名来 结束修复阶段 。 如果您使用 --quick ， myisamchk 不会创建临时 .MYD 文件，而是假定 .MYD 文件正确并且只生成新的索引文件而不触及该 .MYD 文件。 这是安全的，因为 myisamchk会 自动检测 .MYD 文件是否损坏，如果是，则中止修复。 您还可以为 myisamchk 指定 --quick 两次选项 。 在这种情况下， myisamchk 不会中止某些错误（例如重复键错误），而是尝试通过修改 .MYD 文件 来解决它们 。 通常， --quick 只有在可用磁盘空间太少而无法执行正常修复时，才 使用两个 选项。 在这种情况下，您应该在运行 myisamchk 之前至少备份表 。

要检查 MyISAM 表，请使用以下命令：

在大多数情况下，一个简单的 myisamchk 命令没有表名以外的参数就足以检查表。

本节中的讨论描述了如何 在 表（扩展 和 ） 上 使用 myisamchk 。 MyISAM .MYI .MYD

您还可以使用 CHECK TABLE 和 REPAIR TABLE 语句来检查和修复 MyISAM 表。 请参见 第13.7.3.2节“检查表语法” 和 第13.7.3.5节“修复表语法” 。

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

要获取有关错误的更多信息，请运行 perror nnn ， nnn 错误号 在哪里 。 以下示例显示如何使用 perror 查找指示表有问题的最常见错误号的含义：

外壳> perror 126 127 132 134 135 136 141 144 145
MySQL错误代码126 =索引文件崩溃
MySQL错误代码127 =记录文件崩溃
MySQL错误代码132 =旧数据库文件
MySQL错误代码134 =记录已被删除（或记录文件崩溃）
MySQL错误代码135 =记录文件中没有更多空间
MySQL错误代码136 =索引文件中没有更多空间
MySQL错误代码141 =写入或更新时复制唯一键或约束
MySQL错误代码144 =表崩溃，上次修复失败
MySQL错误代码145 =表被标记为崩溃，应该修复

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

ALTER TABLE tbl_nameMAX_ROWS = xxxAVG_ROW_LENGTH = yyy;

如果您不知道当前表选项值，请使用 SHOW CREATE TABLE 。

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

修复过程最多涉及三个阶段，如此处所述。 在开始之前，您应该将位置更改为数据库目录并检查表文件的权限。 在Unix上，确保 mysqld 运行 的用户可以读取它们 （对你而言，因为你需要访问你正在检查的文件）。 如果结果你需要修改文件，它们也必须是你可写的。

本节适用于表检查失败的情况（例如 第7.6.2节“如何检查MyISAM表中的错误”中所述的情况 ），或者您希望使用 myisamchk 提供 的扩展功能 。

用于表维护 的 myisamchk 选项在 第4.6.4节“ myisamchk - MyISAM表维护实用程序”中介绍 。 myisamchk 还有一些变量可以设置为控制可以提高性能的内存分配。 请参见 第4.6.4.6节“myisamchk内存使用” 。

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

第1阶段：检查你的桌子

如果你有更多的时间，请 运行 myisamchk * .MYI 或 myisamchk -e * .MYI 。 使用 -s （静音）选项可以抑制不必要的信息。

如果 mysqld 服务器停止，你应该使用该 --update-state 选项告诉 myisamchk 将表标记为 “已 检查”。 ”

您必须仅修复 myisamchk 宣布错误的 那些表 。 对于此类表格，请转到第2阶段。

如果在检查时遇到意外错误（例如 out of memory 错误），或者 myisamchk 崩溃，请转到第3阶段。

第2阶段：轻松安全维修

首先，尝试 myisamchk -r -q tbl_name （ -r -q 意思是 “ 快速恢复模式 ” ）。 这会尝试修复索引文件而不触及数据文件。 如果数据文件包含它应该包含的所有内容，并且删除链接指向数据文件中的正确位置，则应该可以使用，并且表是固定的。 开始修复下一张桌子。 否则，请使用以下过程：

如果修复时出现意外错误（例如 out of memory 错误），或者 myisamchk 崩溃，请转到第3阶段。

第3阶段：难以修复

只有当索引文件中的第一个16KB块被销毁或包含不正确的信息，或者索引文件丢失时，才应该到达此阶段。 在这种情况下，需要创建一个新的索引文件。 这样做如下：

回到第2阶段 .myisamchk -r -q 应该可以工作。 （这不应该是无限循环。）

您还可以使用 SQL语句，该语句自动执行整个过程。 实用程序和服务器之间也不可能发生不需要的交互，因为服务器在您使用时会完成所有工作 。 请参见 第13.7.3.5节“修复表语法” 。 REPAIR TABLE tbl_name USE_FRM REPAIR TABLE

要合并碎片行并消除因删除或更新行而导致的浪费空间，请 在恢复模式下 运行 myisamchk ：

外壳> myisamchk -r tbl_name

您可以使用 OPTIMIZE TABLE SQL语句 以相同的方式优化表 。 OPTIMIZE TABLE 进行表修复和密钥分析，并对索引树进行排序，以便密钥查找更快。 实用程序和服务器之间也不可能发生不需要的交互，因为服务器在您使用时会完成所有工作 OPTIMIZE TABLE 。 请参见 第13.7.3.4节“OPTIMIZE TABLE语法” 。

myisamchk 还有许多其他选项可用于提高表的性能：

有关所有可用选项的完整说明，请参见 第4.6.4节“ myisamchk - MyISAM表维护实用程序” 。

最好定期执行表检查，而不是等待问题发生。 检查和修复 MyISAM 表的 一种方法 是使用 CHECK TABLE 和 REPAIR TABLE 语句。 请参见 第13.7.3节“表维护声明” 。

检查表的另一种方法是使用 myisamchk 。 出于维护目的，您可以使用 myisamchk -s 。 的 -s 选项（简称 --silent ）导致 myisamchk的 到无声模式运行，印刷消息只有当出现错误。

启用自动 MyISAM 表检查 也是一个好主意 。 例如，只要机器在更新过程中重新启动，您通常需要在进一步使用之前检查可能受影响的每个表。 （这些都是 “ 预计坠毁表 。 ” ），使服务器检查 MyISAM 自动表，与启动 --myisam-recover-options 选项。 请参见 第5.1.7节“服务器命令选项” 。

您还应该在正常系统操作期间定期检查您的表。 例如，您可以运行一个 cron 作业来每周检查一次重要的表，在 crontab 文件中 使用这样的行 ：

35 0 * * 0  - /path/to/myisamchkfast --silent /path/to/datadir/*/*.MYI

这将打印出有关崩溃表的信息，以便您可以根据需要检查和修复它们。

首先， 每晚在所有在过去24小时内更新的表上 执行 myisamchk -s 。 如您所见，问题很少发生，您可以将检查频率提前一周左右。

通常，MySQL表几乎不需要维护。 如果要对 MyISAM 具有动态大小的行（带有 VARCHAR ， BLOB 或 TEXT 列的表）的 表 执行许多更新， 或者对具有许多已删除行的 表 执行许多更新，则 可能需要不时对表中的空间进行碎片整理/回收。 您可以通过使用 OPTIMIZE TABLE 相关表格 来执行此操作 。 或者，如果您可以暂停 mysqld 服务器一段时间，请将位置更改为数据目录，并在服务器停止时使用此命令：

外壳> myisamchk -r -s --sort-index --myisam_sort_buffer_size=16M */*.MYI