请注意，在启用通用查询日志的情况下启动 mysqld 之前，您应该使用 myisamchk 检查所有表。参见 第 7 章，MySQL 服务器管理.

如果 mysqld 崩溃或挂起，您应该启用通用查询日志的情况下启动 mysqld。参见 第 7.4.3 节，“通用查询日志”。当 mysqld 再次崩溃时，您可以检查日志文件末尾以查找导致 mysqld 崩溃的查询。

如果您使用默认的通用查询日志文件，则该日志将存储在数据库目录中，名为 host_name.log 在大多数情况下，它是日志文件中的最后一个查询导致 mysqld 崩溃，但如果可能，您应该通过重新启动 mysqld 并从 mysql 命令行工具执行找到的查询来验证这一点。如果这有效，您还应该测试所有未完成的复杂查询。

您也可以尝试对所有 EXPLAIN 命令，它将花费很长时间来确保 mysqld 正确地使用索引。参见 第 15.8.2 节，“EXPLAIN 语句”.

您可以通过启用慢查询日志的情况下启动 mysqld 来查找执行时间较长的查询。参见 第 7.4.5 节，“慢查询日志”.

如果您在错误日志（通常是名为 host_name.err 的文件）中找到文本 mysqld restarted，则您可能已经找到了导致 mysqld 失败的查询。如果发生这种情况，您应该使用 myisamchk 检查所有表（参见 第 7 章，MySQL 服务器管理），并测试 MySQL 日志文件中的查询，以查看其中一个是否失败。如果您找到了这样的查询，请先尝试升级到最新的 MySQL 版本。如果这不起作用，请报告错误，参见 第 1.6 节，“如何报告错误或问题”.

如果您已启用 myisam_recover_options 系统变量的情况下启动 mysqld，MySQL 会自动检查并尝试修复标记为“未正确关闭”或“崩溃”的 MyISAM 表。如果发生这种情况，MySQL 会在 hostname.err 文件中写入一个条目 'Warning: Checking table ...'，后面跟着 Warning: Repairing table（如果表需要修复）。如果您收到大量此类错误，而 mysqld 之前没有意外死亡，那么出了问题，需要进一步调查。参见 第 7.1.7 节，“服务器命令选项”.

当服务器检测到 MyISAM 表损坏时，它会将附加信息写入错误日志，例如源文件的名称和行号，以及访问该表的线程列表。例如：Got an error from thread_id=1, mi_dynrec.c:368。这些信息对包含在错误报告中很有用。

如果 mysqld 意外死亡，这可不是什么好兆头，但在这种情况下，你不应该调查 Checking table... 消息，而是应该尝试找出 mysqld 死亡的原因。