使用している MySQL ディストリビューションのバージョン番号（MySQL バージョン 4.0.12 など）。実行しているバージョンを確認するには、mysqladmin version を実行する。mysqladmin は、MySQL インストールディレクトリ下の bin ディレクトリにある。

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

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

メモリ（実メモリと仮想メモリ）の量が関連することもある。関連していると思われる場合は、これらの値を記載する。

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

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

mysqld が停止した場合、mysqld のクラッシュの原因となったクエリも報告する必要がある。通常、ログを有効にして mysqld を実行すると、これを検出することができる。 See 項E.1.5. 「mysqld におけるエラーの原因をログファイルを使用して特定する」。

データベーステーブルが問題に関連している場合、mysqldump --no-data db_name tbl_name1 tbl_name2 ... からの出力を記載する。これを行うのは非常に簡単だが、データベース内のテーブルに関する情報を取得する強力な方法である。この情報は、発生した状況と同じ状況を再現する際に役立つ。

SELECT ステートメントの速度に関するバグや問題については、必ず EXPLAIN SELECT ... の出力と、少なくとも SELECT ステートメントによって生成されたレコードの数を記載する必要がある。また、関連する各テーブルの SHOW CREATE TABLE tbl_name からの出力も記載する。発生した状況を説明する情報が詳細であるほど、的確な回答を得られる可能性が高くなる。次は、非常に適切なバグレポートの例である（当然のことながら、mysqlbug スクリプトを使用して投稿されたものである）。

mysql コマンドラインツールを使用して実行したサンプル（出力幅が 80 桁ディスプレイ装置の出力幅を超えるステートメントへの \G ステートメント終端記号の使用に注意）

mysql> SHOW VARIABLES;
mysql> SHOW COLUMNS FROM ...\G
<SHOW COLUMNS からの出力>
mysql> EXPLAIN SELECT ...\G
       <EXPLAIN からの出力>
mysql> FLUSH STATUS;
mysql> SELECT ...;
       <クエリの実行に要した時間を含む、
       SELECT からの簡略な出力>
mysql> SHOW STATUS;
       <SHOW STATUS からの出力>

mysqld の実行中にバグまたは問題が発生した場合、その異常を再現する入力スクリプトを提供する。このスクリプトには、必要なソースファイルを含める必要がある。スクリプトによって再現される状況が実際に発生した状況に近いほど、効果的である。再現可能なテストケースを作成できる場合は、優先的に処理されるように http://bugs.mysql.com/ にそのテストケースを投稿する。

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

数行ではテストケースを再現できない場合や、テストテーブルが大きすぎてメーリングリストに送信できない場合（10 レコードを超えるテーブル）、mysqldump を使用してテーブルをダンプし、問題を説明する README ファイルを作成する必要がある。

tar と gzip または zip を使用してファイルの圧縮アーカイブを作成し、ftp を使用してそのアーカイブを ftp://support.mysql.com/pub/mysql/secret/ に転送する。その後、バグデータベース（http://bugs.mysql.com/）に問題を入力する。

MySQL サーバでクエリによって正しくない結果が生成されたと思う場合、結果だけでなく、正しいと考える結果と、その考えの根拠を示す説明も記載する。

問題のサンプルを提供する際には、新しい名前を使用するよりも、実際の状況で使用している変数名やテーブル名などを使用するのが適切である。問題が、変数やテーブルの名前に関連している可能性があるためである。このようなケースはほとんどないと思われるが、後悔するよりも安全策をとるべきである。結局、実際の状況に基づいたサンプルを提供する方がユーザにとって簡単であると同時に、当社にとっても効率的である。データを他のユーザに公開したくない場合は、ftp を使用して ftp://support.mysql.com/pub/mysql/secret/ に転送することができる。データが実際に最高機密であり、当社にも公開したくない場合は、他の名前を使用したサンプルを提供することもできるが、これは最後の選択肢である。

可能な場合、関連するプログラムのすべてのオプションを記載する。たとえば、mysqld デーモンを開始する際に使用したオプションや MySQL クライアントプログラムの実行に使用したオプションを記載する。mysqld、mysql のようなプログラムのオプションや configure スクリプトのオプションは多くの場合、回答への手がかりとなり、非常に重要である。これらを記載することは、決して無駄ではない。Perl や PHP などのモジュールを使用している場合は、それらのバージョン番号も記載する。

質問が特権システムに関連する場合、mysqlaccess の出力、mysqladmin reload の出力、および接続しようとした際に表示されたすべてのエラーメッセージを記載する。権限をテストする際には、まず mysqlaccess を実行する。その後、mysqladmin reload version を実行し、問題が発生したプログラムに接続する。mysqlaccess は、MySQL インストールディレクトリ下の bin ディレクトリにある。

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

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

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

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

解析エラーが発生した場合、構文を詳細に確認する必要がある。構文に問題が見つからなかった場合は、使用している構文が現在のバージョンの MySQL サーバでサポートされていない可能性が非常に高い。現在のバージョンを使用している場合、使用している構文が http://www.mysql.com/doc/ のマニュアルで扱われていなければ、そのクエリは MySQL サーバでサポートされていない。その場合は、自分で構文を実装するか、<licensing@mysql.com> に電子メールを送信して、その構文を実装するように依頼するしかない。

使用している構文がマニュアルで扱われていても、古いバージョンの MySQL サーバを使用している場合は、MySQL の変更履歴で構文が実装された時期を確認する必要がある。この場合は、新しいバージョンの MySQL サーバにアップグレードする方法がある。 See 付録 D. MySQL Change History。

データが壊れている点が問題である場合や、特定のテーブルにアクセスした際にエラーが発生した場合、myisamchk または CHECK TABLE と REPAIR TABLE を使用して、まずテーブルをチェックしてから、修復を試みる必要がある。 See 章 4. データベース管理。

テーブルが頻繁に壊れる場合、その問題が発生する状況と理由を特定する必要がある。この場合、mysql-data-directory/'hostname'.err ファイルに、発生した問題に関する情報が格納されていることがある。See 項4.10.1. 「エラーログ」。このファイル内の関連する情報をバグレポートに記載する。通常、更新の途中で mysqld が停止されない限り、mysqld によってテーブルが破壊されることはない。mysqld が停止した原因が特定されれば、当社はその問題の解決策をはるかに簡単に提供することができる。 See 項A.1. 「問題の原因を突き止める方法」。

可能な場合、最新バージョンの MySQL サーバをダウンロードしてインストールし、これによって問題が解決されるかどうかを確認する。MySQL ソフトウェアのすべてのバージョンが詳細にテストされているため、問題なく動作するはずである。すべてにおいて最大限の下位互換性が確保されているため、MySQL のバージョンを問題なく切り替えることができると当社は確信している。 See 項2.2.4. 「使用すべき MySQL のバージョン」。