注意: --log を指定して mysqld を起動する前に、すべてのテーブルを myisamchk でチェックしてください。 See 章 4. データベース管理。

mysqld がクラッシュまたはハングした場合、--log を指定して mysqld を起動する必要があります。mysqld が再度クラッシュした場合、ログファイルの末尾を参照し、mysqld のクラッシュを引き起こしたクエリの有無を確認できます。

ファイル名なしで --log を使用している場合、ログは 'hostname'.log としてデータベースディレクトリに格納されます。多くの場合、ログファイル内の最後のクエリが原因で mysqld がクラッシュしています。ただし、実際にそうであったかどうかを確認するため、mysqld を再起動し、検出されたクエリを mysql コマンドラインツールから実行する必要があります（可能な場合）。この方法が有効な場合、完了しなかった複雑なクエリをすべてテストする必要もあります。

時間がかかる SELECT ステートメントのすべてに対してコマンド EXPLAIN を実行し、インデックスが mysqld によって適切に使用されているかどうかを確認することもできます。 See 項5.2.1. 「EXPLAIN 構文（SELECT に関する情報の取得）」。

実行時間の長いクエリを検索するには、--log-slow-queries を指定して mysqld を実行します。 See 項4.10.5. 「スロークエリログ」。

テキスト mysqld restarted がエラーログファイル（通常は hostname.err という名称）に含まれている場合、mysqld のクラッシュを引き起こしたクエリが検出されたと考えられます。この場合、myisamchk（see 章 4. データベース管理）でテーブルをすべてチェックします。また、MySQL ログファイル内のクエリをテストし、いずれかが無効かどうかを確認します。そのようなクエリが見つかった場合、最新バージョンの MySQL へのアップグレードを試みてください。アップグレードしても問題が解決せず、mysql メールアーカイブにも有益な情報がない場合、MySQL メーリングリストにバグをレポートする必要があります。 このメーリングリストが掲載されている http://lists.mysql.com/ には、オンラインリストアーカイブもリンクされています。

myisam-recover を指定して mysqld を起動した際、MyISAM テーブルが '正しく閉じられなかった' または 'クラッシュした' とマークされている場合、そのテーブルは自動的にチェックされ、修復が試行されます。この場合、hostname.err ファイルに 'Warning: Checking table ...' と書き込まれます。また、テーブルの修復が必要であれば、Warning: Repairing table が続いて書き込まれます。これらのエラーが大量に発生した際、直前に mysqld が突然クラッシュしていない場合は異常であり、さらに調査しなければなりません。 See 項4.1.1. 「mysqld コマンドラインオプション」。

mysqld が突然クラッシュするのは、もちろん正常ではありません。ただし、その場合には、Checking table... メッセージを調べるのではなく、mysqld がクラッシュした原因を探してください。