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

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

この章は MySQL メーリングリストを紹介し、それをどのように使用するかのガイドラインを提供します。

2.1 MySQL メーリングリスト

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

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

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

もし、あなたのリプライアドレスが妥当な物でない場合、アドレスを明確に指定することが出来ます。 subscribe あるいは unsubscribe のあとにハイフンを付け、そのあとにあなたのアドレスを記述します。ただし `@' 文字は `=' に置き変えて書きます。例えば、 your_name@host.domain で購読したい場合、 mysql-subscribe-your_name=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: このリストには、完全で再現可能なバグレポートだけを、mysqlbug を使用して投稿すべきです(Windows 上で実行している場合は、OS と MySQL バージョンの記述を含めるべきです)。できれば、投稿前に MySQL の最新の安定バージョンか開発バージョンを使用して問題をテストすべきです！含められたテストケース上で、mysql test < script を使用することで、誰もがバグを再現できるべきです。このリストに投稿された全てのバグは、次の MySQL リリースで修正されるかドキュメント化されます！小さなコードの変更だけですめば、我々はこの問題を修正するパッチの投稿も行ないます。
bugs-digest: ダイジェスト形式の bugs リストです。
developer: MySQL コードを動かす人のためのリスト。このリストでは MySQL 開発の議論とパッチの投稿も可能です。
developer-digest: developer リストのダイジェストバージョン。 internals-digest list (below).
internals: MySQL コード上で作業する人のためのリストこのリストでも MySQL 開発の議論とパッチの投稿が可能です。
internals-digest: internals リストのダイジェストバージョン。
java: MySQL と Java についての議論。多くは JDBC ドライバについてです。
java-digest: java リストのダイジェストバージョン。
win32: Win95, Win98, NT, Win2000 のような Microsoft OS 上の MySQL に関連する全て。
win32-digest: win32 リストのダイジェストバージョン。
myodbc: ODBC で MySQL への接続に関連する全て。
myodbc-digest: myodbc リストのダイジェストバージョン。
plusplus: MySQL の C++ API でのプログラミングについての全て。
plusplus-digest: plusplus リストのダイジェストバージョン。
msql-mysql-modules: MySQL でサポートする Perl についてのリスト。
msql-mysql-modules-digest: msql-mysql-modules リストのダイジェストバージョン。

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

次の表は英語以外の MySQL メーリングリストを示します。注意: これらは MySQL AB によって運用されていません。そのため、我々はそれらの品質を保証できません。

, フランス語メーリングリスト
, 韓国語メーリングリスト: このリストに subscribe mysql your@email.address をメールしてください。
, ドイツ語メーリングリスト: このリストに subscribe mysql-de your@email.address をメールしてください。これについては http://www.4t2.com/mysql で情報を見つけられます。
, ポルトガル語メーリングリスト: このリストに subscribe mysql-br your@email.address をメールしてください。
, スペイン語メーリングリスト: このリストに subscribe mysql your@email.address をメールしてください。

2.2 質問またはバグ報告

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

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

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

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

良いバグレポートを書くのは忍耐が要りますが、それを最初に正しく行なうことは我々とあなたから時間を節約します。そのバグについての完全なテストケースを含む良いバグレポートは、次のリリースでそれが修正される可能性がとても高くなります。この節では、かなりの、または全く我々の助けにならないことにあなたの時間を浪費しないように、あなたがレポートを正しく書くことを手助けします。

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

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

バグや問題を報告する通常の場所は、mysql@lists.mysql.com です。バグを明確に示すテストケースを作ることができれば、 bugs@list.mysql.com リストにそれを投稿してください。注意: このリストには、完全で再現可能なバグ情報を mysqlbug スクリプトを使用して投稿すべきです。 Windows 上で実行している場合は、OS と MySQL バージョンの記述を含めるべきです。できれば、投稿前に MySQL の最新の安定バージョンか開発バージョンを使用して問題をテストすべきです！含められたテストケース上で、'mysql test < script' を使用することで、または、バグレポートに含められたシェル/Perlスクリプトを実行することで、誰もがバグを再現できるべきです。このリストに投稿された全てのバグは、次の MySQL リリースで修正されるかドキュメント化されます！小さなコードの変更だけですめば、我々はこの問題を修正するパッチの投稿も行ないます。

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

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

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

最も役に立つのは、問題の良い説明がバグレポートに含められることです。つまり、問題に導かれる全ての行なったことの例と、正確に記述された問題それ自身です。良いバグレポートは、バグや問題を再現する方法を示す完全な例を含むものです。「I.1.5 Making a test case when you experience table corruption」節参照.

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

MyODBC での問題がある場合、MyODBC トレースファイルの生成を試みるべきです。「19.7 Reporting Problems with MyODBC」節参照。

あなたのレポートを読む多くの人が 80桁ディスプレイを使用しているということを覚えておいて下さい。従って、mysql コマンドラインツールを使用してレポートまたはサンプルを生成する時、そのようなディスプレイの有効幅を超える出力(例えば、EXPLAIN SELECT ステートメント; 後述のサンプルを見てください)には、--vertical オプション(または \G ステートメント終端)を使用すべきです。

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

使用している MySQL 配布のバージョン番号 (例えば MySQL バージョン 3.22.22)。どのバージョンを動かしているかは mysqladmin version の実行でわかります。mysqladmin は MySQL のインストールディレクトリ配下の `bin' ディレクトリに見つけられます。
あなたが作業しているマシンのメーカーとモデル。
オペレーティングシステム名とバージョン。多くのオペレーティングシステムでは、UNIX コマンド uname -a の実行によってこの情報が得られます。
時にはメモリ(実メモリと仮想メモリ)の量も関係します。疑わしければ、それを含めてください。
MySQL のソース配布を使用している場合は、使用したコンパイラの名前とバージョン番号につての情報も必要です。バイナリ配布の場合は、配布名が必要です。
問題がコンパイル中に発生する場合、正確なエラーメッセージと、エラーが発生したファイルの問題のコードの回りの数行も含めて下さい。
もし mysqld が死んだ場合は、mysqld がクラッシュしたクエリもレポートしてください。通常、これはロギングが有効な mysqld の実行によって、見つけられます。「I.1.4 Using log files to find cause of errors in mysqld」節参照。
何かのデータベーステーブルが問題に関連する場合は、 mysqldump --no-data db_name tbl_name1 tbl_name2 ... からの出力を含めてください。これはデータベース内の任意のテーブルについての情報を得るとても簡単で強力な方法で、我々があなたの状況に一致するものを生成する手助けになります。
SELECT ステートメントでの速度に関するバグや問題では、 EXPLAIN SELECT ... の出力と、少なくとも SELECT ステートメントが与える行の数を常に含めるべきです。あなたの状況について、より多くの情報を、誰かがあなたを助けられるように、より適切に与えてください！例えば、次はとても良いバグレポートの例です（もちろん mysqlbug スクリプトで投稿されてます）: mysql コマンド行ツール配下での実行例(注意: 出力幅がディスプレイ装置の80桁を超えるステートメントには、\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>
```
問題やバグが MySQL 実行中に発生する場合、バグを再現する入力スクリプトが必要です。このスクリプトは必要なソースファイル全てを含めるべきです。より精密なスクリプトはあなたのに似た状況を良く再現できます。テストケースを再現可能にできる場合は、高い優先度で取り扱われるように、 bugs@lists.mysql.com にそれを送ってください！もしスクリプトを提供することができなければ、少なくとも、 mysqladmin variables extended-status processlist の出力結果をメールにを含むべきです。これはあなたのシステムの情報を提供します！
数行のテストケースを提供できない場合、またはテストテーブルがメーリングリストにメールするには大きすぎる(10行以上)場合、mysqldump を使用してあなたのテーブルをダンプし、あなたの問題を説明した `README' ファイルを作るべきです。 tar と gzip または zip を使用して、ファイルの圧縮アーカイブを生成し、そのアーカイブを ftp を使用して ftp://support.mysql.com/pub/mysql/secret/ に転送してください。それから問題の短い説明を mysql@lists.mysql.com に送ってください。
MySQL がクエリから異常な結果を与えると思う場合は、結果だけでなく、結果がどうなるべきかというあなたの意見と、あなたの意見の基本を説明する理由も含めてください。
問題のサンプルを提供する時に、新しい名前にするよりも、実際の状況で存在するのと同じ変数名やテーブル名等を使用した方が良いです。問題は変数やテーブルの名前に関連することがあります！おそらくこれはまれなケースですが、 sorry よりも safe の方が良いです。結局、実際に持っているあなたのサンプル中の同じ状況を使用することはあなたにとっても簡単で、我々にとっても全ての意味で良いことです。他の人に見せたくないデータをいくつか持っている場合、 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' ディレクトリに見つけられます。
あなたがバグについてのパッチを持っているのは良い事ですが、そのパッチがすべて、我々が求めているもので、あなたのパッチが修正するバグのテスト情報を提供しなくても、我々がそれを使用するだろう、と思わないでください。我々はあなたのパッチに問題を見つけるかもしれませんし、または、それを全く理解できないかもしれません。その場合はそれを使用できません。そのパッチに意味があることが正確に確かめられなければ、我々はそれを使用しません。テストケースは我々にこの手助けをします。パッチが起りうる全ての状況を扱うことを示してください。パッチが動作しない境界線のケース(それが稀でも)を見つけた場合、パッチは使用されないでしょう。
何がバグか、何故発生するのか、何に依存しているのか、についての推測は通常間違いです。我々でさえ、まずデバッガを使用してバグの実際の原因を見つけなければ、そのことは推測できません。
メールメッセージ中に、あなたがリファレンスマニュアルとメールアーカイブをチェックしたことを示してください。そうすれば、あなたの問題をあなた自身で解決しようとしたことを他の人がわかります。
parse error が発生する場合、構文を厳密にチェックしてください！何が間違っているのかを見つけられなければ、多分、使用しているクエリを MySQL の現在のバージョンがサポートしていないということです。現在のバージョンを使用していて、http://www.mysql.com/documentation/manual.php のマニュアルがあなたの使用しているクエリ構文をカバーしていない場合は、これは MySQL があなたのクエリをサポートしていないという意味です。この場合、あなたの選択は、その構文をあなた自身で実装することか、 mysql-support@mysql.com に email でこれを実装するように申し込むことです！マニュアルがあなたの使用している構文をカバーしているのにMySQL の古いバージョンを使用している場合、文法が実装された時期について MySQL の変更履歴をチェックすべきです。「F MySQL change history」節参照。この場合、より新しいバージョンの MySQL へのアップグレードを選択できます。
もしあなたのデータが悪くなったように思えたり、または、ある特定のテーブルにアクセスする時、エラーとなるなら、まず最初に、テーブルを myisamchk か CHECK TABLE/REPAIR TABLE 文で検査し、修復を試みるべきです「16 Maintaining a MySQL Installation」節参照.
もししょっちゅうテーブルがダメになるようなら、いつ、なぜ起こるのかを探し出すべきです！この場合、`mysql-data-directory/'hostname'.err' ファイルに何が起こっているのか含まれている場合があります。「23.1 The Error Log」節参照. このファイルから関連する情報を抜きだしバグレポートに含めてください！通常、 mysqld は更新の最中に kill されない限りはテーブルを絶対に破壊しません！もしなぜ mysqld が死ぬのか見つけた場合は、我々があなたに問題解決のための修正を提供することが、はるかに簡単になります! 「21.1 How to Determine What Is Causing Problems」節参照
可能な場合、最新の MySQL バージョンをダウンロードして、これで問題が解決されるかどうかをチェックしてください。全ての MySQL バージョンは通してテストされ、問題なしに動作します！全てが可能な限り以前と互換があるように作られていて、すぐに MySQL バージョンを切り替えることができると我々は信じています！「4.3 使用する MySQL バージョン」節参照。

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

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

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

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

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

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

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

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

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

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