まず、https://dev.mysql.com/doc/ で MySQL オンラインマニュアルを検索してください。 マニュアルは、常に最新の状態にしておくために、新しく見つかった問題に対する解決策によって頻繁に更新されています。 また、問題に関する解決方法が新しいバージョンにすでに組み込まれている可能性が高いので、マニュアルに付随するリリースノートは特に有用です。 リリースノートはマニュアル用の場所から入手可能です。

SQL ステートメントに対するパースエラーが生じた場合は、構文を念入りにチェックしてください。 そこで問題が見当たらなければ、現在使用している MySQL Server のバージョンが、使用されている構文をサポートしていない可能性が高くなります。 最新のバージョンを使用しており、マニュアルが使用された構文をカバーしていない場合、MySQL Server はそのステートメントをサポートしません。

マニュアルがその構文をカバーしているが、MySQL Server が旧バージョンの場合、MySQL の変更履歴を調べ、いつその構文が実装されたのかを確認してください。 この場合、新しいバージョンの MySQL Server へアップグレードするという選択肢もあります。

一般的な問題の解決法については次を参照してください。セクションB.3「問題および一般的なエラー」。

http://bugs.mysql.com/ でバグデータベースを検索して、バグがすでにレポートおよび解決されているかどうかを確認します。

http://www.mysql.com/search/ を使用して、MySQL web サイトにあるすべての Web ページ (マニュアルを含む) を検索することもできます。

使用している MySQL ディストリビューションのバージョン番号 (MySQL 5.7.10 など)。 実行しているバージョンを確認するには、mysqladmin version を実行します。 mysqladmin プログラムは、MySQL インストールディレクトリの下の bin ディレクトリにあります。

問題が発生したマシンの製造元とモデル。

オペレーティングシステムの名前とバージョン。 Windows を使用している場合、名前とバージョン番号を取得するには、通常「マイコンピュータ」アイコンをダブルクリックし、「ヘルプ/バージョン情報」メニューをプルダウンします。 ほとんどの Unix 系のオペレーティングシステムでは、この情報を取得するには、コマンド uname -a を実行します。

メモリー (実メモリーと仮想メモリー) の量が関連することもあります。 不確かな場合は、これらの値を記載します。

MySQL インストールの docs/INFO_BIN ファイルの内容。 このファイルには、MySQL の構成およびコンパイル方法に関する情報が含まれています。

MySQL ソフトウェアのソースディストリビューションを使用している場合、使用したコンパイラの名前とバージョン番号を記載します。 バイナリディストリビューションを使用している場合は、ディストリビューション名を記載します。

コンパイル時に問題が発生した場合、正確なエラーメッセージ、およびエラーが発生したファイル内の問題のあるコード付近の数行のコンテキストを記載します。

mysqld が停止した場合は、mysqld が予期せず終了する原因となったステートメントも報告する必要があります。 通常、この情報を取得するには、クエリーロギングを有効にして mysqld を実行し、mysqld の終了後にログを参照します。 セクション5.9「MySQL のデバッグ」を参照してください。

データベーステーブルが問題に関連している場合、SHOW CREATE TABLE db_name.tbl_name ステートメントからの出力をバグレポートに記載します。 これは、データベース内のテーブルの定義を取得する非常に簡単な方法です。 この情報は、発生した状況と同じ状況を再現する際に役立ちます。

問題発生時の SQL モードも有効な情報になる場合があるので、sql_mode システム変数の値をレポートしてください。 ストアドプロシージャー、ストアドファンクション、およびトリガーオブジェクトでは、関連する sql_mode の値は、そのオブジェクトが作成された際に有効だったものです。 ストアドプロシージャーまたはストアドファンクションでは、SHOW CREATE PROCEDURE または SHOW CREATE FUNCTION ステートメントは関連する SQL モードを示しています。また、INFORMATION_SCHEMA で情報を問い合わせできます。

SELECT ROUTINE_SCHEMA, ROUTINE_NAME, SQL_MODE
FROM INFORMATION_SCHEMA.ROUTINES;

トリガーに対しては次のステートメントが利用できます。

SELECT EVENT_OBJECT_SCHEMA, EVENT_OBJECT_TABLE, TRIGGER_NAME, SQL_MODE
FROM INFORMATION_SCHEMA.TRIGGERS;

性能に関連するバグや SELECT ステートメントに関する問題については、EXPLAIN SELECT ... の出力、および少なくとも SELECT ステートメントが生成する行の数も含めてください。 関連する各テーブルについて、SHOW CREATE TABLE tbl_name からの出力も含めてください。 状況について情報を提供できればできるほど、有効な手助けが可能となります。

下記は非常によいバグレポートの例です。 mysql コマンド行ツールを使ってステートメントが実行されています。 読みにくい長い出力行に対して、\G ステートメントターミネータが使用されていることに注意してください。

mysql> SHOW VARIABLES;
mysql> SHOW COLUMNS FROM ...\G
       <output from SHOW COLUMNS>
mysql> EXPLAIN SELECT ...\G
       <output from EXPLAIN>
mysql> FLUSH STATUS;
mysql> SELECT ...;
       <A short version of the output from SELECT,
       including the time taken to run the query>
mysql> SHOW STATUS;
       <output from SHOW STATUS>

mysqld の実行中にバグまたは問題が発生した場合、その異常を再現する入力スクリプトを提供します。 このスクリプトには、必要なソースファイルを含める必要があります。 スクリプトによって再現される状況が実際に発生した状況に近いほど、効果的です。 再現可能なテストケースを作成できる場合は、バグレポートに添付してアップロードしてください。

スクリプトを提供できない場合は、少なくとも mysqladmin variables extended-status processlist からの出力をレポートに記載して、システムの動作に関する情報を提供してください。

数行ではテストケースを再現できない場合や、テストテーブルが大きすぎてバグレポートに含めることができない場合 (10 行を超える場合)、mysqldump を使用してテーブルをダンプし、問題を説明する README ファイルを作成してください。 tar と gzip または zip を使用してファイルの圧縮アーカイブを作成します。 http://bugs.mysql.com/ のバグデータベースのバグレポートを開始してから、バグレポートの「ファイル」タブをクリックして、アーカイブをバグデータベースにアップロードする指示に従ってください。

MySQL Server でステートメントから正しくない結果が生成されたと思う場合、結果だけでなく、正しいと考える結果と、その考えの根拠を示す説明も記載します。

問題のサンプルを提供する際には、テーブル名や変数名などは、新しい名前を使用するよりも実際の状況で存在するものを使用するのが適切です。 問題が、テーブルや変数の名前に関連している可能性があります。 このようなケースはほとんどないと思われますが、後悔するよりも安全策をとるべきです。 結局、実際の状況に基づいたサンプルを提供する方がユーザーにとって簡単であると同時に、当社にとっても効率的です。 バグレポート内に、ほかのユーザーに公開したくないデータがある場合は、前述のように「ファイル」タブを使用してアップロードできます。 データが実際に最高機密で、当社にも公開したくない場合は、ほかの名前を使用したサンプルを提供することもできますが、これは最後の選択肢です。

可能な場合、関連するプログラムのすべてのオプションを記載します。 たとえば、mysqld サーバーを開始する際に使用したオプションや MySQL クライアントプログラムの実行に使用したオプションを記載します。 mysqld や mysql のようなプログラムや、configure スクリプトのオプションは多くの場合、問題解決の鍵となり、非常に重要です。 これらを記載することは、決して無駄ではありません。 問題が、Perl や PHP などの言語で記述されたプログラムに関係する場合は、言語プロセッサーのバージョン番号だけでなく、プログラムが使用するモジュールのバージョンも記載します。 たとえば、DBI モジュールや DBD::mysql モジュールを使用する Perl スクリプトがある場合、Perl、DBI、および DBD::mysql のバージョン番号を記載します。

質問が権限システムに関連する場合は、mysqladmin reload の出力と、接続しようとしたときに表示されるすべてのエラーメッセージを含めてください。 権限をテストする場合は、mysqladmin reload version を実行し、問題のあるプログラムに接続してみてください。

バグのパッチがある場合、それを含めます。 ただし、当社はパッチだけを必要としているわけではありません。パッチによって修正されるバグを示すテストケースなどの必要な情報が記載されていない場合、当社はそのパッチを使用できません。 当社がパッチに関連する問題を見つける場合もあれば、パッチをまったく理解できない場合もあります。 そのような場合は、パッチを使用できません。

パッチの目的を正確に確認することができない場合、当社はそのパッチを使用しません。 この場合、テストケースが役立つことになります。 発生する可能性があるすべての状況がパッチによって処理されることを示してください。 パッチが機能しないボーダーラインケースが見つかった場合 (それがまれなケースでも) 、そのパッチは役に立たない可能性があります。

何がバグであるか、そのバグがなぜ発生するのか、そのバグが何に関連するのかについての推測は、間違っていることが多いです。 MySQL チームでさえも、最初にデバッガを使用しなければ、そのようなことを推測してバグの実際の原因を特定することはできません。

ユーザー自身で問題を解決しようとしたことがほかのユーザーにわかるように、リファレンスマニュアルやメールアーカイブを確認したことをバグレポートに記載します。

データが壊れていると思われる場合や、特定のテーブルにアクセスした際にエラーが発生した場合は、まず CHECK TABLE でテーブルをチェックしてください。 そのステートメントでエラーがレポートされた場合、

Windows を実行している場合は、lower_case_table_names の値を SHOW VARIABLES LIKE 'lower_case_table_names' ステートメントを使用して確認します。 この変数は、データベースおよびテーブル名の大文字/小文字をサーバーがどのように扱うかに対して影響を与えます。 ある値に対しての効果は セクション9.2.3「識別子の大文字と小文字の区別」 で説明されているとおりです。

テーブルが頻繁に壊れる場合、その問題が発生する状況と理由を特定する必要があります。 この場合、MySQL データディレクトリのエラーログに、発生した問題に関する情報が格納されていることがあります。 (そのファイルは、名前に .err のサフィクスが付いたファイルです。) セクション5.4.2「エラーログ」 を参照してください。 このファイル内の関連する情報をバグレポートに記載します。 通常、更新中に何も強制終了しなかった場合、mysqld はテーブルを破損させないでください。 mysqld が停止した原因が特定されれば、当社はその問題の解決策をはるかに簡単に提供できます。 セクションB.3.1「問題の原因を判別する方法」 を参照してください。

可能な場合、最新バージョンの MySQL Server をダウンロードしてインストールし、これによって問題が解決されるかどうかを確認します。 MySQL ソフトウェアのすべてのバージョンが詳細にテストされているため、問題なく動作するはずです。 すべてにおいて最大限の下位互換性が確保されているため、MySQL のバージョンを問題なく切り替えることができると当社は確信しています。 セクション2.1.2「インストールする MySQL のバージョンと配布の選択」 を参照してください。