10bet网址
MySQL 5.6リファレンスマニュアル
本手册下载
PDF (Ltr)- 26.8 mb
PDF (A4)- 26.8 mb


MySQL 5.6リファレンスマニュアル/一般情報/質問またはバグをレポートする方法

1.6質問またはバグをレポートする方法

問題についてバグレポートを投稿する前に,それが実際にバグであることと,バグがまだレポートされていないことを確認してください。

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

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

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

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

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

  • http://lists.10bet靠谱mysql.com/でMySQLメーリングリストのアーカイブを検索します。1.5.1“MySQLメーリングリスト”を参照してください。

  • またhttp://www.m10bet靠谱ysql.com/search/を使用して,MySQL WebサイトにあるWebページすべて(マニュアルを含む)を検索することもできます。

マニュアル,バグデータベース,およびメーリングリストのアーカイブで回答を見つけることができなかった場合,お近くのMySQLの専門家にお問い合わせください。それでも質問に対する回答を見つけることができなかった場合は,次のガイドラインに従ってバグをレポートしてください。

通常バグをレポートする場合は,http://bugs.10bet靠谱mysql.com/にアクセスしてください。これはバグデータベースのアドレスです。このバグデータベースは一般に公開されているので,だれでも参照および検索することができます。システムにログインすると,新しいレポートを入力できます。

http://bugs.10bet靠谱mysql.com/のバグデータベースに投稿され,所定のリリースで修正されたバグは,リリースノートに記載されます。

MySQL服务器で慎重に扱うべきセキュリティー上のバグを発見した場合は,ただちにに電子メールメッセージを送信してお知らせください。例外:サポートのお客様は,セキュリティーのバグを含むすべての問題をhttp://support.oracle.com/のOracle支持までレポートしてください。

ほかのユーザーと問題について話し合う場合,MySQLメーリングリストのいずれかを使用することもできます。1.5.1“MySQLメーリングリスト”

よいバグレポートを書くのは時間がかかるものですが,最初に正しく行うことで報告者と弊社の双方の時間を節約できます。そのバグの完全なテストケースを含むよいバグレポートを提供していただければ,次回のリリースではその問題を修正できる可能性が非常に高くなります。このセクションでは,あまり役に立たないことをして時間を無駄にすることがないよう,レポートの正しい書き方を紹介します。このセクションを注意深く読み,ここに記載されているすべての情報がレポートに含まれているか,確認してください。

できればMySQL服务器の最新の製品版または開発版を使用して問題をテストしてから投稿してください。テストケースに対してMysql测试脚本文件を使用するか,バグレポートに含まれているシェルまたはPerlのスクリプトを実行するだけで,だれでもバグを再現できるはずです。弊社で再現が可能なバグであれば,次回のMySQLリリースで修正される可能性が高くなります。

問題に関する適切な説明がバグレポートに記載されていると,もっとも効果的です。そのため,問題につながったすべての操作の適切な例を挙げ,問題自体を詳細に記述してください。もっとも効果的なレポートは,バグや問題を再現する方法を示す詳細な例が記載されたものです。セクション24.4 MySQLのデバッグおよび移植を参照してください。

情報が多すぎるレポートに対応することはできますが,少なすぎるレポートに対応することはできません。多くの場合,問題の原因がわかっていると思い,細部を重要でないと考えるため,事実を省略してしまいます。記載するかどうかを迷ったときは,記載することをお勧めします。最初のレポートに十分な情報を記載していなかったために,再度質問して回答を待たなければならなくなるよりも,レポートに数行を追加する方が,はるかに時間が節約される上に,煩わしくありません。

バグレポートでもっともよくある誤りは,(a)使用しているMySQLディストリビューションのバージョン番号を記載していない,(b) MySQL服务器がインストールされているプラットフォームの説明(プラットフォームの種類およびバージョン番号を含む)が十分でないというものです。これは非常に重要な情報なので,ほとんどの場合,この情報が記載されていないバグレポートは役に立ちません。なぜうまく動作しないのか?という質問が頻繁に寄せられます。その場合,要求した機能がそのMySQLバージョンに実装されていなかったり,レポートに記載されているバグが新しいMySQLバージョンですでに修正されていたりすることがあります。エラーがプラットフォーム依存である場合もよくあります。そのような場合,オペレーティングシステムやプラットフォームのバージョン番号を知らないで問題を修正することはほとんど不可能です。

またMySQLをソースからコンパイルした場合は,コンパイラが問題に関連している場合は,コンパイラに関する情報も記載してください。ユーザーがコンパイラのバグを見つけて,それがMySQL関連の問題であると考えることがよくあります。ほとんどのコンパイラは常に開発中なので,バージョンごとに改良されています。問題がコンパイラに関連するものであるかどうかを判断するには,使用しているコンパイラを知る必要があります。コンパイルに関するすべての問題はバグとみなし,適宜レポートしてください。

プログラムでエラーメッセージが生成された場合,そのメッセージをレポートに記載することが非常に重要です。アーカイブから情報を検索しようとする場合,レポートされたエラーメッセージがプログラムで生成されたものと正確に一致している方が効果的です。(大文字小文字の違いにも注意してください)エラーメッセージ全体をレポートにコピー&ペーストしてください。記憶に頼ってエラーメッセージを思い出そうとしないでください。

连接器/ ODBC (MyODBC)に関する問題がある場合,トレースファイルを生成し,レポートともに送信してください。如何报告连接器/ODBC问题或bugを参照してください。

レポートに,mysqlコマンド行ツールを使用して実行したテストケースからの長いクエリー出力が含まれる場合,——垂直オプション(または\ Gステートメントターミネータ)を使用すると,読みやすくなります。このセクションで後述される解释选择の例では,\ Gの使用方法を示します。

レポートには次の情報を記載してください。

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

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

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

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

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

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

  • mysqldが停止した場合,mysqldのクラッシュの原因となったステートメントもレポートする必要があります。通常,クエリーのロギングを有効にしてmysqldを実行して,mysqldがクラッシュしたあとでログを調べることでこの情報を取得できます。セクション24.4 MySQLのデバッグおよび移植を参照してください。

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

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

    从information_schema.routines中选择routine_schema, routine_name, sql_mode;

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

    从information_schema.triggers中选择event_object_schema, event_object_table, trigger_name, sql_mode;
  • 性能に関連するバグや选择ステートメントに関する問題については,解释选择……の出力,および少なくとも选择ステートメントが生成する行の数も含めてください。関連する各テーブルについて,显示创建表tbl_nameからの出力も含めてください。状況について情報を提供できればできるほど,有効な手助けが可能となります。

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

    mysql >显示变量;mysql>显示从< SHOW COLUMNS的输出>mysql> EXPLAIN SELECT<输出解释>mysql >冲洗状态;mysql >选择…;SELECT输出的短版本,包括运行查询>所花费的时间mysql >显示状态;< SHOW STATUS>输出
  • mysqldの実行中にバグまたは問題が発生した場合,その異常を再現する入力スクリプトを提供します。このスクリプトには,必要なソースファイルを含める必要があります。スクリプトによって再現される状況が実際に発生した状況に近いほど,効果的です。再現可能なテストケースを作成できる場合は,バグレポートに添付してアップロードしてください。

    スクリプトを提供できない場合は,少なくともMysqladmin变量扩展状态processlistからの出力をレポートに記載して,システムの動作に関する情報を提供してください。

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

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

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

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

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

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

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

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

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

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

    • InnoDBクラッシュリカバリメカニズムは,サーバーが強制終了したあとに再起動した場合にクリーンアップを処理します。そのため,通常の操作ではテーブルを修復する必要はありません。InnoDBテーブルでエラーが生じる場合は,サーバーを再起動して問題が継続するかどうか,またはエラーがメモリー内のキャッシュデータのみに影響するのかを確認します。ディスク上のデータが壊れている場合,影響を受けたテーブルをダンプできるように,innodb_force_recoveryオプションを有効にして再起動してみてください。

    • トランザクショナルでないテーブルについては,修理表またはmyisamchkを使用して修復を試みてください。第5章「MySQLサーバーの管理を参照してください。

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

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

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


本手册下载
PDF (Ltr)- 26.8 mb
PDF (A4)- 26.8 mb