極めて固有な問題が起きた場合は、いつでも MySQL のデバッグを試みることができます。デバッグするには、--with-debug または --with-debug=full オプションを指定して MySQL を設定する必要があります。 MySQL がコンパイルされたかどうかをチェックするには、mysqld --help を実行します。--debug オプションが表示されたらデバッグは有効です。この場合、mysqladmin ver を実行すると、mysqld バージョンが mysql ... --debug として表示されます。

gcc または egcs の使用時には、以下の configure 行が推奨されています。

CC=gcc CFLAGS="-O2" CXX=gcc CXXFLAGS="-O2 -felide-constructors \
   -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql \
   --with-debug --with-extra-charsets=complex

これによって、libstdc++ ライブラリと C++ 例外に関する問題が回避され（多くのコンパイラでは、スレッドコードで C++ 例外が発生します）、すべてのキャラクタセットのサポート付きで MySQL がコンパイルされます。

メモリオーバーランエラーの疑いがある場合、--with-debug=full オプションを指定して MySQL を設定し、メモリ割当（SAFEMALLOC）チェッカをインストールできます。ただし、SAFEMALLOC を指定して実行すると非常に遅くなるので、パフォーマンスの問題が生じたときには mysqld を --skip-safemalloc オプションで起動してください。これによって、malloc() と free() に対する呼び出しのたびにメモリオーバーランのチェックが無効になります。

mysqld が --with-debug 付きのコンパイル時にクラッシュしなくなった場合、コンパイラバグまたはタイミングバグが MySQL で検出されたと考えられます。この場合、上記の CFLAGS および CXXFLAGS 変数に -g を追加し、--with-debug を指定しない方法を試みることができます。mysqld がクラッシュした場合、少なくとも gdb を使用してアタッチするか、コアファイル上で gdb を実行して何が起きたか確認することは可能です。

デバッグ用に MySQL を設定すると、多くの特別なチェック関数が自動的に有効になり、これらによって mysqld の状態が監視されます。 ``予期しない'' 状態が検出された場合、stderr にエントリが書き込まれ、mysqld_safe によってエラーログに送信されます。つまり、予期しない問題が MySQL で発生したときにソースディストリビューションを使用している場合、まず MySQL をデバッグ用に設定する必要があります。その後は MySQL メーリングリストにメールを送信し、ヘルプを依頼してください。 See 項1.7.1.1. 「MySQL メーリングリスト」。 ご利用の MySQL バージョンに関するバグレポートまたは質問については、mysqlbug を使用してください。

Windows 版 MySQL ディストリビューションでは、mysqld.exe がデフォルトでコンパイルされています（トレースファイルのサポート付き）。

mysqld サーバが起動しないか mysqld サーバですぐにクラッシュが起きる場合、トレースファイルを作成して問題の検出を試みることができます。

そのためには、mysqld をデバッグ用にコンパイルしておく必要があります。そのようにコンパイルされているか確認するには、mysqld -V を実行します。バージョン番号の末尾が -debug である場合、トレースファイルのサポート付きでコンパイルされています。

/tmp/mysqld.trace（Windows では C:\mysqld.trace）内のトレースログを指定して mysqld サーバを起動します。

mysqld --debug

Windows では、--standalone フラグを使用し、mysqld がサービスとして起動されないようにする必要もあります。

コンソールウィンドウで以下を実行します。

mysqld --debug --standalone

この後、mysql.exe コマンドラインツールを 2 番目のコンソールウィンドウで実行し、問題を再現することができます。mysqladmin shutdown では、mysqld サーバを強制終了することができます。

注意: トレースファイルは非常に大きなサイズになります。 トレースファイルのサイズを小さくしたい場合、たとえば以下のように指定することができます。

mysqld --debug=d,info,error,query,general,where:O,/tmp/mysqld.trace

（この場合、最も興味深いタグの付いた情報のみが /tmp/mysqld.trace に出力されます。）

これに関するバグレポートを作成する場合、不具合があると思われる行のみをトレースファイルから選択し、適切なメーリングリスト宛てに送信してください。不具合の場所を特定できない場合には、トレースファイルと完全なバグレポートを ftp://support.mysql.com/pub/mysql/secret/ まで ftp で送信してください。MySQL の開発者側で確認させていただきます。

トレースファイルは、Fred Fish による DBUG パッケージで作成されています。 See 項E.3. 「DBUG パッケージ」。

多くのシステムでは、mysqld がクラッシュした際に、mysqld を gdb から起動することで、より多くの情報を取得することもできます。

Linux で使用される旧バージョンの gdb の一部では、mysqld スレッドをデバッグする際に run --one-thread を使用しなければなりません。この場合、一度にアクティブにできるスレッドは 1 つだけです。速やかに gdb 5.1 にアップグレードすることをお奨めします。このバージョンでは、スレッドデバッグの処理が大幅に改善されるからです。

gdb で mysqld を実行する場合、スタックトレースを --skip-stack-trace で無効化し、gdb 内部で segfault を捕捉できるようにする必要があります。

MySQL 4.0.14 以降では、mysqld に対して --gdb オプションを使用してください。このオプションを使用すると、SIGINT（mysqld を ^C で終了し、ブレークポイントを設定するために必要）の割り込みハンドラがインストールされ、スタックトレースとコアファイル処理が無効になります。

gdb で MySQL をデバッグするのが非常に困難な場合があります。たとえば、古いスレッドに対するメモリが gdb によって解放されず、デバッグ中に大量の新規接続を連続して確立しなければならない場合です。この問題を回避するには、-O thread_cache_size= 'max_connections +1' を指定して mysqld を起動します。多くの場合、-O thread_cache_size=5' を指定するだけで状況は大幅に改善します。

SIGSEGV シグナルで mysqld がクラッシュした場合、Linux 上でコアダンプを取得するには、--core-file オプションを指定して mysqld を起動します。 このコアファイルを使用してバックトレースを作成し、mysqld がクラッシュした理由を特定することもできます。

shell> gdb mysqld core
gdb>   backtrace full
gdb>   exit

See 項A.4.1. 「MySQL が何度もクラッシュする場合に行うこと」。

gdb 4.17.x 以降を Linux で使用している場合、.gdb ファイルを以下の情報と共にカレントディレクトリにインストールする必要があります。

set print sevenbit off
handle SIGUSR1 nostop noprint
handle SIGUSR2 nostop noprint
handle SIGWAITING nostop noprint
handle SIGLWP nostop noprint
handle SIGPIPE nostop
handle SIGALRM nostop
handle SIGHUP nostop
handle SIGTERM nostop noprint

gdb でスレッドのデバッグに問題が起きた場合、gdb 5.x をダウンロードして代用してみてください。gdb の新規バージョンでは、スレッドの処理が飛躍的に改善されています。

以下の例は、mysqld をデバッグする方法を示します。

shell> gdb /usr/local/libexec/mysqld
gdb> run
...
backtrace full # Do this when mysqld crashes

mysqlbug で生成された上記の出力内容をメールに取り込み、通常の MySQL メーリングリスト宛てに送信してください。 See 項1.7.1.1. 「MySQL メーリングリスト」。

mysqld がハングした場合、strace や /usr/proc/bin/pstack のようなシステムツールを使用し、mysqld がハングした場所を調べることができます。

strace /tmp/log libexec/mysqld

Perl DBI インタフェースを使用している場合、デバッグ情報を有効にするには、trace メソッドを使用するか DBI_TRACE 環境変数を設定します。 See 項11.5.2. 「DBI インタフェース」。

一部のオペレーティングシステムでは、mysqld が突然クラッシュするとスタックトレースがエラーログに記録されます。この情報を使用すると、mysqld がクラッシュした場所（および理由）を確認することができます。See 項4.10.1. 「エラーログ」。 スタックトレースを取得する場合、mysqld のコンパイルを -fomit-frame-pointer オプション付き gcc で行わないでください。 See 項E.1.1. 「MYSQL のコンパイル（デバッグ用）」。

エラーファイルの内容が以下のとおりであるとします。

mysqld got signal 11;
The manual section 'Debugging a MySQL server' tells you how to use a
stack trace and/or the core file to produce a readable backtrace that may
help in finding out why mysqld died
Attemping backtrace. You can use the following information to find out
where mysqld died.  If you see no messages after this, something went
terribly wrong
stack range sanity check, ok, backtrace follows
0x40077552
0x81281a0
0x8128f47
0x8127be0
0x8127995
0x8104947
0x80ff28f
0x810131b
0x80ee4bc
0x80c3c91
0x80c6b43
0x80c1fd9
0x80c1686

mysqld がクラッシュした場所を特定するには、以下を実行します。

注意: --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 がクラッシュした原因を探してください。

テーブルが破損しているか、更新コマンドの後に mysqld が必ずエラーになる場合、この問題が再現されるかテストするには以下を実行します。

スクリプト mysql_find_rows で一部の更新ステートメントのみを実行し、問題を絞り込むこともできます。