MySQL 8.0 リファレンスマニュアル MySQL NDB Cluster 8.0 を含む
このページは機械翻訳したものです。
一般クエリーログを有効にして mysqld を起動する前に、myisamchk を使用してすべてのテーブルをチェックしてください。 第5章「MySQL サーバーの管理」 を参照してください。
mysqld が異常終了またはハングアップする場合は、一般クエリーログを有効にして mysqld を起動してください。 セクション5.4.3「一般クエリーログ」を参照してください。 mysqld がふたたび異常終了したら、ログファイルの最後の部分を調査して、mysqld が強制終了されたクエリーを見つけることができます。
デフォルトの一般クエリーログファイルを使用した場合、ログはデータベースディレクトリに
として格納されます。ほとんどの場合、mysqld が強制終了されたのはログファイル内の最後のクエリーですが、可能であれば、mysqld を再起動して、見つかったクエリーを mysql コマンド行ツールから実行することによって、このことを検証してください。 これが機能する場合は、完了しなかった複雑なクエリーもすべてテストする必要があります。
host_name
.log
また、長い時間がかかるすべての SELECT
ステートメントに対して EXPLAIN
コマンドを試すことで、mysqld がインデックスを適切に使用していることを確認できます。 セクション13.8.2「EXPLAIN ステートメント」を参照してください。
実行に長い時間がかかるクエリーを見つけるには、スロークエリーログを有効にして mysqld を起動します。 セクション5.4.5「スロークエリーログ」を参照してください。
エラーログ (通常は
という名前のファイル) にテキスト host_name
.errmysqld restarted
が見つかった場合、mysqld が失敗する原因となるクエリーが見つかった可能性があります。 これが発生した場合、myisamchk を使用してすべてのテーブルをチェックし (第5章「MySQL サーバーの管理」を参照してください)、MySQL ログファイル内のクエリーをテストして、失敗するかどうかを確認します。 そのようなクエリーが見つかった場合は、まず最新バージョンの MySQL にアップグレードすることを試してください。 問題が解決しない場合は、バグを報告してください。セクション1.6「質問またはバグをレポートする方法」 を参照してください。
myisam_recover_options
システム変数を設定して mysqld を起動した場合、MyISAM
テーブルが正しくクローズされていないまたはクラッシュとマークされていれば、MySQL によって自動的にチェックされ、修復が試行されます。 これが発生した場合、MySQL は hostname.err
ファイルに「警告: テーブル ... をチェックしています」
と書き込み、テーブルを修復する必要がある場合は、「警告: テーブルを修復しています」
がそのあとに書き込まれます。 これらのエラーを多数受け取り、その直前に予期しない mysqld の停止がなかった場合は、何らかの問題があるため、さらに調査する必要があります。 セクション5.1.7「サーバーコマンドオプション」を参照してください。
サーバーは、MyISAM
テーブルの破損を検出すると、ソースファイルの名前や行番号、テーブルにアクセスするスレッドのリストなどの追加情報をエラーログに書き込みます。 たとえば、「thread_id=1 からエラーを受け取りました。mi_dynrec.c:368」
です。 これは、バグレポートに含めると役に立つ情報です。
mysqld が予期せず異常終了することは良い兆候ではありませんが、この場合は Checking table...
メッセージを調査するのではなく、mysqld が異常終了した原因を見つけるようにしてください。