Go to the first, previous, next, last section, table of contents.

2 MySQL メーリングリストと質問をする方法またはエラー(バグ)を報告する方法

2.1 MySQL メーリングリスト

メイン MySQL メーリングリストを購読するには、メッセージを電子メールアドレス mysql-subscribe@lists.mysql.com に送ってください。

メイン MySQL メーリングリストの購読の中止は、メッセージを電子メールアドレス mysql-unsubscribe@lists.mysql.com に送ってください。

メッセージを送る先のアドレスだけが重要です。メッセージのサブジェクトと本文は無視されます。

もし、あなたのリプライアドレスが妥当な物でない場合、アドレスを明確に指定することが出来ます。 subscribe あるいは unsubscribe のあとにハイフンを付け、そのあとにあなたのアドレスを記述します。ただし `@' 文字は `=' に置き変えて書きます。例えば、 john@host.domain で購読したい場合、 mysql-subscribe-john=host.domain@lists.mysql.com 宛にメッセージを送ります。

mysql-subscribe@lists.mysql.com や mysql-unsubscribe@lists.mysql.com へのメールは ezmlm メーリングリストプロセッサによって自動的に処理されます。 ezmlm についての情報は the ezmlm Website.

本メーリングリストへの投稿を行うには、mysql@lists.mysql.com にメッセージを送ります。しかし、subscribe あるいは unsubscribe のメールを mysql@lists.mysql.com に送らないでください。これらのアドレスへ送られたメールは、何千ものユーザーに配送されてしまいます。

あなたのローカルサイトが多くの mysql@lists.mysql.com 購読者を持つこともあります。この場合、ローカルメーリングリストを作り、lists.mysql.com からの一つのメッセージがそのサイトに送られ、ローカルなリストで複写されるようにしてください。この場合、ローカルの MySQL リストへの追加と削除は、あなたのシステム管理者に問い合わせて下さい。

次の MySQL メーリングリストがあります:

announce: これは MySQL と関連プログラムの新しいバージョンのアナウンスのためです。これは、全ての MySQL ユーザが入るべきと我々が考える少ない量のリストです。
mysql: 一般の MySQL 議論のための主なリストです。さらに専門的なリストに行くべきものもあることに注意してください。間違ったリストに投稿しても、答を得られないでしょう！
mysql-digest: ダイジェスト形式の mysql リストです。これは、一日に一回、一つの大きなメールが送られることで個々のメッセージ全てが得られることを意味します。
bugs: On this list you should only post a full, repeatable bug report, using the mysqlbug script (if you are running on Windows, you should include a description of the operating system and the MySQL version). Preferably, you should test the problem using the latest stable or development version of MySQL before posting! Anyone should be able to repeat the bug by just using 'mysql test < script' on the included test case. All bugs posted on this list will be corrected or documented in the next MySQL release! If there are only small code changes involved, we will also post a patch that fixes the problem.
bugs-digest: The bugs list in digest form
developer: MySQL コードを動かす人のためのリスト。 On this list one can also discuss MySQL development and post patches.
developer-digest: A digest version of the developer list.
java: MySQL と Java についての議論。多くは JDBC ドライバについてです。
java-digest: A digest version of the java list.
win32: Windows NT のような Microsoft OS 上の MySQL に関連する全て。
win32-digest: A digest version of the win32 list.
myodbc: ODBC で MySQL への接続に関連する全て。
myodbc-digest: A digest version of the myodbc list.
msql-mysql-modules: MySQL でサポートする Perl についてのリスト。
msql-mysql-modules-digest: msql-mysql-modules リストのダイジェストバージョン。

上述したのと同じ方法で全てのリストの購読または購読中止ができます。あなたの購読または購読中止のメッセージは、mysql ではなく適切なメーリングリストに送ってください。例えば、 myodbc リストを購読または購読中止するには、 myodbc-subscribe@lists.mysql.com または myodbc-unsubscribe@lists.mysql.com にメールを送ります。

2.2 質問またはバグ報告

メーリングリストへ質問を尋ねる前に、以下の手順を踏んでください：

MySQL のオンラインマニュアルを調べることからはじめます：
```
http://www.mysql.com/Manual_chapter/manual_toc.html
```
我々は、新しく見つかった問題の解決でマニュアルを頻繁に更新することで、それを最新に保持しようとしています！
MySQL メーリングリストアーカイブを検索します：
```
http://www.mysql.com/doc.html
```
http://www.mysql.com/ の全ての Web ページ(マニュアルも含む)を検索するために http://www.mysql.com/search.html も使用できます。

ここで回答が見つけられない場合は、近くの MySQL 熟練者とともに調べて下さい。まだあなたの質問の回答が見つけられなければ、先に進み、次のセクションの mysql@lists.mysql.com へメールを送る方法についてを読んでください。

2.3 バグや問題を報告する方法

良いバグレポートを書くのは忍耐が要りますが、それを最初に正しく行なうことは我々とあなたから時間を節約します。 A good bug report containing a full test case for the bug will make it very likely that we will fix it in the next release. この節では、かなりの、または全く我々の助けにならないことにあなたの時間を浪費しないように、あなたがレポートを正しく書くことを手助けします。

我々は、バグレポートまた可能ならば全ての問題についてのレポートの作成に mysqlbug スクリプトを使用することを奨励します。mysqlbug はソース配布内の `scripts' ディレクトリ、または、バイナリ配布では MySQL をインストールしたディレクトリ配下の `bin' ディレクトリから見つけられます。mysqlbug を使用できない場合は、この節に挙げられている全ての必要な情報を含めるべきです。

mysqlbug スクリプトは、下記の多くの情報を自動的に見つけ出すことで、レポートの作成を手助けします。しかし、重要な何かが足りない場合、あなたのメッセージにそれを含めてください！この節を慎重に読んで、ここで述べられている全ての情報がレポート中に含まれていることを確認してください。

If you can make a test case which clearly shows the bug, you should post it to the bugs@list.mysql.com list. Note that on this list you should only post a full, repeatable bug report, using the mysqlbug script (if you are running on Windows, you should include a description of the operating system and the MySQL version). Preferably, you should test the problem using the latest stable or development version of MySQL before posting! Anyone should be able to repeat the bug by just using 'mysql test < script' on the included test case or run the shell / perl script that is included in the bug report. All bugs posted on this list will be corrected or documented in the next MySQL release! If there are only small code changes involved, to correct this problem, we will also post a patch that fixes the problem.

多すぎる情報を含むメッセージに答えることはできますが、少なすぎる情報を含むものにはできないということを覚えていてください。しばしば人は事実を省いてしまいます。問題の原因をわかっていると思い、いくつかの詳細を重大でないと見なしてしまうからです。良い原則は: 何かを言おうか迷ったときには、言ってください！最初にあなたが十分な情報を含めなかったために、再び質問して回答を待つことを強要されるより、数行をあなたのレポートに書く方が千倍速くて迷惑ではありません。

良くある間違いは、使用している MySQL 配布のバージョン番号を示さない、または MySQL をインストールしたプラットフォームを(プラットフォームのバージョン番号を含めて)示さない事です。これはとても関連した情報で、100 のバグレポートのうち 99 の場合、この情報がないと役に立ちません！我々は ``何故私では動作しないの？'' のような質問をとても良く受けます。そして我々は、要求された機能はその MySQL バージョンに実装されていない、または、レポート中に述べられているバグは新しい MySQL バージョンで既に修正されているであることを見つけます。時々、エラーはプラットフォーム依存で、オペレーティングシステムとプラットフォームのバージョン番号を知らないことには、何も修正することはできません。

問題に関連している場合は、コンパイラについての情報も与えることを忘れないでください。しばしば人はコンパイラのバグを見つけて、問題は MySQL に関連していると考えます。多くのコンパイラはいつも開発中で、バージョンを上げることによってより良いバージョンになります。問題がコンパイラに依存しているかどうかを確定するには、どのコンパイラが使用されているかを知ることが必要です。全てのコンパイルの問題はバグレポートとみなされ、それに従って報告されるべきであることに注意してください。

最も役に立つのは、問題の良い説明がバグレポートに含められることです。つまり、問題に導かれる全ての行なったことの例と、正確に記述された問題それ自身です。良いバグレポートは、バグや問題を再現する方法を示す完全な例を含むものです。

問題がエラーメッセージを与える場合、それをレポートに含めることはとても重要です！我々がプログラムを使用するアーカイブから何かを検索しようとする場合、エラーメッセージはプログラムが与えたものと正確に一致する方が良いです(大文字小文字も守られるべきです！)。どのようなエラーメッセージだったかを覚えるなんてことはしてはいけません；レポートに完全なメッセージをコピーし張りつけてください。

If you have a problem with MyODBC, you should try to genereate a MyODBC trace file. 「18.6 Reporting problems with MyODBC」節参照.

Please remember that many of the people who will read your report will do so using an 80-column display. When generating reports or examples using the mysql command line tool, you should therefore use the --vertical option (or the \G statement terminator) for output which would exceed the available width for such a display (for example, with the EXPLAIN SELECT statement; see the example below).

次の情報をレポートに含めてください:

使用している MySQL 配布のバージョン番号 (例えば MySQL 3.22.22)。どのバージョンを動かしているかは mysqladmin version の実行で見つけられます。mysqladmin は MySQL のインストールディレクトリ配下の `bin' ディレクトリに見つけられます。
あなたが作業しているマシンのメーカーとモデル。
オペレーティングシステム名とバージョン。多くのオペレーティングシステムでは、Unix コマンド uname -a の実行によってこの情報が得られます。
時にはメモリ(実メモリと仮想メモリ)の量も関係します。疑わしければ、それを含めてください。
MySQL のソース配布を使用している場合は、使用したコンパイラの名前とバージョン番号につての情報も必要です。バイナリ配布の場合は、配布名が必要です。
問題がコンパイル中に発生する場合、正確なエラーメッセージと、エラーが発生したファイルの問題のコードの回りの数行も含めて下さい。
何かのデータベーステーブルが問題に関連する場合は、 mysqldump --no-data db_name tbl_name1 tbl_name2 ... からの出力を含めてください。これはデータベース内の任意のテーブルについての情報を得るとても簡単で強力な方法で、我々があなたの状況に一致するものを生成する手助けになります。
SELECT ステートメントでの速度に関するバグや問題では、 EXPLAIN SELECT ... の出力と、少なくとも SELECT ステートメントが与える行の数を常に含めるべきです。あなたの状況について、より多くの情報を、誰かがあなたを助けられるように、より適切に与えてください！例えば、次はとても良いバグレポートの例です（もちろん mysqlbug スクリプトで投稿されてます）: mysql コマンド行ツール配下での実行例(note the use of the +\G statement terminator for statements whose output width would +otherwise exceed that of an 80-column display device):
```
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>
```
問題やバグが MySQL 実行中に発生する場合、バグを再現する入力スクリプトが必要です。このスクリプトは必要なソースファイル全てを含めるべきです。より精密なスクリプトはあなたのに似た状況を良く再現できます。もしスクリプトを提供することができなければ、少なくとも、 mysqladmin variables extended-status processlist の出力結果をメールにを含むべきです。これはあなたのシステムの情報を提供します！
MySQL がクエリから異常な結果を与えると思う場合は、結果だけでなく、結果がどうなるべきかというあなたの意見と、あなたの意見の基本を説明する理由も含めてください。
問題のサンプルを提供する時に、新しい名前にするよりも、実際の状況で存在するのと同じ変数名やテーブル名等を使用した方が良いです。問題は変数やテーブル等の名前に関連することがあります！おそらくこれはまれなケースですが、 sorry よりも safe の方が良いです。結局、実際に持っているあなたのサンプル中の同じ状況を使用することはあなたにとっても簡単で、我々にとっても全ての意味で良いことです。他の人に見せたくないデータをいくつか持っている場合、 ftp を使用して ftp://www.mysql.com/pub/mysql/secret/ にデータを転送することができます。データが本当に最高機密で我々にさえ見せたくない場合は、先に進んで、他の変数名等を使用してサンプルを作ってみてください。しかしこれは最後の選択と思ってください。
可能ならば、関連プログラムに与えられた全てのオプションを含めてください。例えば、mysqld デーモン開始時に使用したオプションと MySQL クライアントプログラム実行に使用したオプションを示してください。。mysqld, mysql または configure スクリプトへのオプションはしばしば回答へのキーになり、とても関連しています！とにかくそれらを含めるというのは悪い考えではありません！ Perl や PHP などのモジュールを使用している場合、それらのバージョン番号も含めてください。
数行のテストケースを提供できない場合、またはテストテーブルがメーリングリストにメールするには大きすぎる(10行以上)場合、mysqldump を使用してあなたのテーブルをダンプし、あなたの問題を説明した `README' ファイルを作るべきです。 tar と gzip または zip を使用して、ファイルの圧縮アーカイブを生成し、そのアーカイブを ftp を使用して ftp://www.mysql.com/pub/mysql/secret/ に転送してください。それから問題の短い説明を mysql@lists.mysql.com に送ってください。
質問が権限システムに関連する場合、mysqlaccess の出力、 mysqladmin reload の出力、接続しようとした時に得られた全てのエラーメッセージを含めてください！権限をテストする時、まず mysqlaccess を実行すべきです。その後、mysqladmin reload version を実行し、最後に問題が発生するプログラムでの接続を試みるべきです。mysqlaccess はMySQL インストールディレクトリ配下の `bin' ディレクトリに見つけられます。
あなたがバグについてのパッチを持っている場合、それは良いです。しかし、そのパッチがすべて、我々が求めているもので、あなたのパッチが修正するバグを示すテストケースのような必要な情報を提供しなくても、我々がそれを使用する、と思わないでください。我々はあなたのパッチで問題を見つけるかもしれませんし、または、それを全く理解できないかもしれません。その場合はそれを使用できません。そのパッチに意味があることが正確に確かめられなければ、我々はそれを使用しません。テストケースは我々にこの手助けをします。パッチが起りうる全ての状況を扱うことを示してください。パッチが動作しない境界線のケース(それが稀でも)を見つけた場合、パッチは使用されないでしょう。
何がバグか、何故発生するのか、何に依存しているのか、についての推測は通常間違いです。我々でさえ、まずデバッガを使用してバグの実際の原因を見つけなければ、そのことは推測できません。
メールメッセージ中に、あなたがリファレンスマニュアルとメールアーカイブをチェックしたことを示してください。そうすれば、あなたの問題をあなた自身で解決しようとしたことを他の人がわかります。
パースエラーが発生する場合、構文を厳密にチェックしてください！何が間違っているのかを見つけられなければ、多分、使用しているクエリを MySQL の現在のバージョンがサポートしていないということです。現在のバージョンを使用していて、http://www.mysql.com/doc.html のマニュアルがあなたの使用しているクエリ構文をカバーしていない場合は、これは MySQL があなたのクエリをサポートしていないという意味です。この場合、あなたの選択は、その構文をあなた自身で実装することか、 mysql-support@mysql.com に email でこれを実装するように申し込むことです！マニュアルがあなたの使用している構文をカバーしているのにMySQL の古いバージョンを使用している場合、文法が実装された時期について MySQL の変更履歴をチェックすべきです。「E MySQL change history」節参照。この場合、より新しいバージョンの MySQL へのアップグレードを選択できます。
もしあなたのデータが悪くなったように思えたり、または、ある特定のテーブルにアクセスする時、エラーとなるなら、まず最初に、テーブルを myisamchk で検査し、修復を試みるべきです「15 Maintaining a MySQL installation」節参照.
もししょっちゅうテーブルがダメになるようなら、いつ、なぜ起こるのかを探し出すべきです！この場合、`mysql-data-directory/'hostname'.err' ファイルに何が起こっているのか含まれている場合があります。このファイルから関連する情報を抜きだしバグレポートに含めてください！通常、 mysqld は更新の最中に kill されない限りはテーブルを絶対に破壊しません！もしなぜ mysqld が死ぬのか見つけた場合は、我々があなたに問題解決のための修正を提供することが、はるかに簡単になります! 「20.1 How to determinate what is causing problems」節参照
可能な場合、最新の MySQL バージョンをダウンロードして、これで問題が解決されるかどうかをチェックしてください。全ての MySQL バージョンは通してテストされ、問題なしに動作します！全てが可能な限り以前と互換があるように作られていて、すぐに MySQL バージョンを切り替えることができると我々は信じています！「4.3 使用する MySQL バージョン」節参照。

あなたがサポート顧客なら、より高い優先順位で取り扱うため mysql-support@mysql.com にバグレポートをクロスポストしてください。同様に、他の誰かが問題を経験済み(そしておそらく解決済み)かどうかを知るために適切なメーリングリストにも。

MyODBC のバグ報告上の情報については、「18.3 MyODBCでの問題をどのように報告すべきか？」節を参照してください。

いくつかの一般的な問題の解決法のために → 「20 問題とよくあるエラー」節参照.

回答があなたに個人的に送られて、メーリングリストに送られていない時、回答を要約し、あなたの問題の解決の手助けになった返事の恩恵を他の人にも与えるために、その要約をメーリングリストに送信することは、良いエチケットです！

2.4 メーリングリストで質問に答えるためのガイドライン

あなたの回答が広く関心を持たれると考えられる場合、尋ねた人に個人的に直接返事をする代わりに、メーリングリストに投稿したいと思うでしょう。オリジナルの投稿者以外の人もそれから恩恵を受けられるように十分一般的に回答を作成することを試みてください。メーリングリストに投稿する場合は、あなたの回答が以前の回答と重複していないか確認して下さい。

あなた返事の中で、質問の本質部分の要約を試みてください。質問全体を引用することを義務と感じないで下さい。

HTML モードを ON にしたブラウザからメールメッセージを投稿しないでください！多くのユーザはブラウザでメールを読んでいません！

Go to the first, previous, next, last section, table of contents.