時間を節約する。

アプリケーションのパフォーマンスを向上させる。

余分なハードウェアの必要性を低減または排除して、コストを削減する。

セキュリティを強化する。

顧客および同僚の満足度を向上させる。

MySQL 検定の準備をする。

MySQL ソフトウェアの GPL コードとプログラムをリンクし、商用製品を作成するため、または追加した非 GPL コードを他の理由でクローズソースにするために、作成する製品に GPL に基づくライセンスを付与しない場合。商用ライセンスを購入すると、MySQL ソフトウェアを使用する際に、同じコードでも GPL が適用されなくなる。

MySQL ソフトウェアのみを使用する非 GPL アプリケーションを提供し、MySQL ソフトウェアとともに出荷する場合。このタイプのソリューションは、ネットワーク経由で行われてもリンクしていると見なされる。

GPL ライセンスの下で必要とされるソースコードの提供を行わずに、MySQL ソフトウェアのコピーを提供する場合。

形式上は商用ライセンスが必要でなくても、MySQL データベースの今後の開発をサポートする場合。MySQL AB からサポートを直接購入することは、MySQL ソフトウェアの開発に貢献するもう 1 つのよい方法である。また、ユーザにも直接メリットがある。 See 項1.4.1. 「MySQL AB によって提供されるサポート」。

独自のアプリケーションと GPL に基づく MySQL のソースコードの両方を製品とともに提供する場合。

商用としてディストリビューションを販売する場合でも、機能に関して MySQL システムにリンクしていない、または MySQL システムに依存していない他のプログラムとバンドルされた MySQL のソースコードを提供する場合。これは、GPL ライセンスでは単に集約と呼ばれる。

MySQL システムのいずれの部分も提供しない場合、無償で使用することができる。

インターネットサービスプロバイダ（ISP）として、MySQL サーバを使用した Web ホスティングを顧客に提供する場合。当社は、MySQL サポートがある ISP を使用するように推奨している。これは、MySQL のインストールに関して発生しうる問題を解決するためのリソースが、実際にそれらの ISP にあるという信頼感が得られるためである。ISP に MySQL サーバの商用ライセンスがなくても、適切なパッチが適用されていることを確認できるように、顧客に少なくとも MySQL インストールのソースへの読み取りアクセス権を付与する必要がある。

MySQL データベースソフトウェアを Web サーバとともに使用する場合（提供する製品でない限り）、商用ライセンスは不要である。MySQL サーバを使用する市販の Web サーバを実行する場合も、同様である。これは、MySQL システムのいずれの部分も提供しないためである。ただし、この場合、MySQL ソフトウェアによって企業がサポートされているので、MySQL サポートを購入していただくよう希望する。

http://www.mysql.com/ サイトに表示されているように、必要なロゴを使用する。必要に応じてロゴのサイズを変更することはできるが、色やデザインを変更したり、グラフィックを変更したりすることはできない。

MySQL の商標を掲載するサイトの作成者および所有者が MySQL AB ではなく、ユーザ自身であることを明確にする。

MySQL AB や MySQL AB の商標の価値にマイナスとなるような使い方をしない。当社は、MySQL AB の商標の使用権を無効にする権利を留保している。

Web サイトで商標を使用する場合、クリックすると、直接 http://www.mysql.com/ にジャンプするようにする。

アプリケーションで GPL に基づく MySQL データベースを使用する場合、アプリケーションはオープンソースであると同時に、MySQL サーバに接続可能でなければならない。

Web サイト以外の場所に MySQL AB のロゴを掲載する場合

前述の条件付き使用ロゴ以外の MySQL AB のロゴを Web サイトやその他の場所に掲載する場合

速度の向上

組み込み MySQL サーバの導入

標準としての InnoDB ストレージエンジン

新機能

標準への準拠、移植性、および移行

国際化

使いやすさの向上

新しいユーザ向けの機能を実装するプロセスでも、既存のユーザの忠実なコミュニティからの要望を忘れることはありません。

サブクエリと派生テーブルのサポート

速度の向上

新機能

標準への準拠、移植性、および移行

国際化

使いやすさの向上

announce

このリストは、新しいバージョンの MySQL および関連するプログラムの通知に使用される。これは、すべての MySQL ユーザが購読する必要がある、ボリュームの小さいリストである。

mysql

これは、MySQL に関する一般的なディスカッションに使用されるメインのリストである。トピックによっては、より専門的なリストでディスカッションを行ったほうがよいものもある。適切でないリストに投稿すると、回答が得られないことがある。

mysql-digest

これは、ダイジェスト形式の mysql リストである。このリストを購読すると、全リストのメッセージを受け取ることになる。これは、1 日 1 回大きなメールメッセージとして送信される。

bugs

これは、MySQL の最新リリース以降に報告された問題を常に把握しておきたいユーザや、バグの検出と修正のプロセスに積極的に参加したいユーザにとって興味深いリストである。 See 項1.7.1.3. 「バグまたは問題を報告する方法」。

bugs-digest

これは、ダイジェスト形式の bugs リストである。

internals

このリストは、MySQL コードに携わる人を対象としている。また、MySQL の開発およびポストパッチに関するディスカッションを行うフォーラムでもある。

internals-digest

これは、ダイジェスト形式の internals リストである。

mysqldoc

このリストは、MySQL AB の従業員、翻訳者、およびその他のコミュニティメンバなど、MySQL のマニュアルに携わる人を対象としている。

mysqldoc-digest

これは、ダイジェスト形式の mysqldoc リストである。

benchmarks

このリストは、パフォーマンスに関する問題に関心がある人を対象としている。データベースのパフォーマンス（MySQL に限らない）に関するディスカッションが中心だが、カーネル、ファイルシステム、ディスクシステムのパフォーマンスなど、より広範なカテゴリも含まれる。

benchmarks-digest

これは、ダイジェスト形式の benchmarks リストである。

packagers

このリストは、MySQL のパッケージおよびディストリビューションに関するディスカッションに使用される。これは、MySQL のパッケージに関するアイデアや、サポートされているすべてのプラットフォームおよびオペレーティングシステムでできる限り同じような MySQL の外観を確保するためのアイデアを交換するためにディストリビューション管理者によって使用されるフォーラムである。

packagers-digest

これは、ダイジェスト形式の packagers リストである。

java

このリストは、MySQL サーバおよび Java に関するディスカッションに使用される。MySQL Connector/J を含む、JDBC ドライバに関するディスカッションに使用されることがほとんどである。

java-digest

これは、ダイジェスト形式の java リストである。

win32

このリストは、Windows 9x/Me/NT/2000/XP などの Microsoft オペレーティングシステムで実行される MySQL ソフトウェアに関するすべてのトピックに使用される。

win32-digest

これは、ダイジェスト形式の win32 リストである。

myodbc

このリストは、ODBC を使用した MySQL サーバへの接続に関するすべてのトピックに使用される。

myodbc-digest

これは、ダイジェスト形式の myodbc リストである。

mysqlcc

このリストは、MySQL Control Center グラフィカルクライアントに関するすべてのトピックに使用される。

mysqlcc-digest

これは、ダイジェスト形式の mysqlcc リストである。

plusplus

このリストは、MySQL への C++ API を使用したプログラミングに関するすべてのトピックに使用される。

plusplus-digest

これは、ダイジェスト形式の plusplus リストである。

msql-mysql-modules

このリストは、現在 DBD-mysql と呼ばれている msql-mysql-modules を使用した MySQL の Perl サポートに関するすべてのトピックに使用される。

msql-mysql-modules-digest

これは、ダイジェスト形式の msql-mysql-modules リストである。

<mysql-france-subscribe@yahoogroups.com> フランス語のメーリングリスト , <list@tinc.net> 韓国語のメーリングリスト

このリストに subscribe mysql your@e-mail.address を電子メールでお送りください。

<mysql-de-request@lists.4t2.com> ドイツ語のメーリングリスト

このリストに subscribe mysql-de your@e-mail.address を電子メールでお送りください。このメーリングリストについては、http://www.4t2.com/mysql/ を参照してください。

<mysql-br-request@listas.linkway.com.br> ポルトガル語のメーリングリスト

このリストに subscribe mysql-br your@e-mail.address を電子メールでお送りください。

<mysql-alta@elistas.net> スペイン語のメーリングリスト

このリストに subscribe mysql your@e-mail.address を電子メールでお送りください。

次の場所で MySQL のオンラインマニュアルを検索する。 http://www.mysql.com/doc/ マニュアルは、常に最新の状態にしておくために、新しく見つかった問題に対する解決策によって頻繁に更新されている。問題に対する解決策が新しいバージョンにすでに組み込まれている可能性が高いので、変更履歴に関する付録（http://www.mysql.com/doc/en/News.html）は特に便利である。

バグデータベース（http://bugs.mysql.com/）を検索して、バグがすでに報告/解決されているかどうかを確認する。

次の場所で MySQL メーリングリストのアーカイブを検索する。 http://lists.mysql.com/

また、http://www.mysql.com/search/ を使用して、http://www.mysql.com/ にある Web ページすべて（マニュアルを含む）を検索することもできる。

使用している 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 のバージョン」。

LOCK TABLES を使用して、通常はトランザクションを必要とするループをコード化することができる。そのため、実行中にレコードを更新するカーソルが不要である。

ROLLBACK を使用しないように、以下の方法を使用することができる。

これは通常、ロールバックが行われる可能性があるトランザクションを使用するよりも、はるかに速い方法である。ただし、更新の途中でスレッドが停止された場合は、この方法では対応することができない。その場合、すべてのロックが解除されるが、一部の更新が実行されていない可能性がある。

関数を使用して、1 回の操作でレコードを更新することもできる。次のようなテクニックを使用すると、非常に効率的なアプリケーションを取得することができる。

たとえば、顧客情報に対して更新を行う場合、変更された顧客データのみを更新し、変更されたデータ、または変更されたデータに依存するデータが元のレコードと比較して変更されていないことだけをテストする。変更されたデータのテストは、UPDATE ステートメントで WHERE 節を使用して行われる。レコードが更新されなかった場合、''Some of the data you have changed has been changed by another user.'' というメッセージがクライアントに表示される。その場合、ウィンドウに元のレコードと新しいレコードを表示して、使用する必要がある顧客レコードのバージョンをユーザが決定できるようにする。

これによって、カラムロックと類似しているが、現在の値に関連する値を使用して、カラムの一部のみが更新される点で、実際はカラムロックよりすぐれた機能が実現する。つまり、一般的な UPDATE ステートメントは次のようになる。

UPDATE tablename SET pay_back=pay_back+125;

UPDATE customer
  SET
    customer_date='current_date',
    address='new address',
    phone='new phone',
    money_he_owes_us=money_he_owes_us-125
  WHERE
    customer_id=id AND address='old address' AND phone='old phone';

これは非常に効率的で、別のクライアントが pay_back または money_he_owes_us カラムの値を変更していても動作する。

多くの場合、ユーザは、複数のテーブルの一意の識別子を管理するために ROLLBACK や LOCK TABLES を使用していた。これは、AUTO_INCREMENT カラムおよび SQL 関数 LAST_INSERT_ID() または C API 関数 mysql_insert_id() を使用することで、はるかに効率的に処理することができる。 See 項11.1.3.32. 「mysql_insert_id()」。

通常、行レベルのロックをコード化することができる。状況によっては実際にこれが必要なので、InnoDB テーブルでは行レベルのロックがサポートされている。MyISAM では、テーブルでフラグカラムを使用し、以下のようなことを実行することができる。

UPDATE tbl_name SET row_flag=1 WHERE id=ID;

レコードが見つかり、元のレコードで row_flag がすでに 1 でなくなっていた場合、MySQL は、影響を受けたレコードの数として 1 を返す。

MySQL サーバでは前述のクエリが次のように変更されると考えることができる。

UPDATE tbl_name SET row_flag=1 WHERE id=ID AND row_flag <> 1;

関係が適切に設計されている場合、外部キー制約によって、プログラマがデータベースで不整合を引き起こすことが少なくなる。

連鎖更新および削除を使用すると、クライアントコードを単純化することができる。

適切に設計された外部キールールは、テーブル間の関係の記述に役立つ。

キー関係を設計する上で犯しやすい間違いによって、循環ルール、連鎖削除の不適切な組み合わせなどの深刻な問題が生じることがある。

データベースレベルでの余分なチェックによって、パフォーマンスに影響が生じる。そのため、一部の主要な商用アプリケーションでは、アプリケーションレベルでこのロジックがコード化されている。

DBA にとって、個々のテーブルのバックアップやリストアが非常に困難になり、場合によっては不可能になるような複雑な関係のトポロジを作成することはめったにない。

複数のテーブルに対して LOCK TABLE を実行した後、別のスレッドがテーブルをロックしようとしている間に同じ接続でそれらのテーブルのいずれかに対して DROP TABLE を実行した場合、デッドロックが発生することがある。ただし、関連するスレッドのすべてに KILL を実行することで、この問題を解決することができる。4.0.12 で修正済み。

テーブルのいずれかが空の場合、SELECT MAX(key_column) FROM t1,t2,t3... が NULL を返す代わりに、カラムの最大値を返す。4.0.11 で修正済み。

ロックされた HEAP テーブルで、WHERE を含まない DELETE FROM heap_table が動作しない。

FLUSH TABLES WITH READ LOCK によって CREATE TABLE または COMMIT がブロックされず、テーブルおよびバイナリログの完全バックアップを実行すると、バイナリログの位置に関する問題が発生する。

BDB テーブルでの ANALYZE TABLE によって、mysqld を再実行するまでテーブルが使用できなくなることがある。この問題が発生した場合は、MySQL エラーファイルに次のようなエラーが生成される。

001207 22:07:56  bdb:  log_flush: LSN past current end-of-log

MySQL では FROM 部でかっこを使用することができるが、自動的に無視される。エラーを生成しない理由は、クエリを自動的に生成する多くのクライアントで、不要な場合でも FROM 部にかっこが付け加えられるためである。

同じクエリ内で多数の RIGHT JOINS を連結した場合や LEFT および RIGHT 結合を組み合わせた場合、LEFT 結合の前のテーブルまたは RIGHT 結合の前のテーブルについて NULL 行のみが生成されるので、正しい結果が得られないことがある。これは、FROM 部におけるかっこのサポートの追加と同時に、5.0 で修正する予定である。

マルチステートメントトランザクションを実行している BDB テーブルでは、それらのトランザクションすべてが完了するまで ALTER TABLE を実行しない（ほとんどの場合、トランザクションは無視される）。

ANALYZE TABLE、OPTIMIZE TABLE、および REPAIR TABLE によって、INSERT DELAYED を使用しているテーブルで問題が発生することがある。

LOCK TABLE ... および FLUSH TABLES ... を実行しても、処理が進行中の未完了のトランザクションがテーブルにないとは限らない。

BDB テーブルを開くのに多少時間がかかる。データベースに多数の BDB テーブルがあるときに、-A オプションを使用していない場合や rehash を使用している場合、データベース上で mysql クライアントを使用するのに時間がかかる。これは、大きなテーブルキャッシュがある場合に特に顕著である。

レプリケーションではクエリレベルのログが使用される。つまり、マスタによって、実行されたクエリがバイナリログに書き込まれる。これは非常に速く、コンパクトで効率的なログ方法であり、ほとんどの場合に問題なく機能する。実際に発生した例を聞いたことはないが、データの変更が非決定論的、つまりクエリオプティマイザの判断で行われるようにクエリが設計されている場合（レプリケーションの外部でも、通常は適切な方法でない）、マスタおよびスレーブのデータが理論的に異なる可能性がある。たとえば、次のような場合である。

これらのクエリすべてに決定論的順序を保証する ORDER BY 節がない場合のみである。

実際、たとえば、ORDER BY がない INSERT ... SELECT の場合、SELECT は、マスタおよびスレーブでオプティマイザによって行われる選択によっては、異なる順序でレコードを返すことがある（その結果、レコードに異なるランクが設定され、auto_increment カラムで異なる数を取得することになる）。マスタとスレーブでクエリが異なって最適化されるのは、以下の場合のみである。

また、この問題は、mysqlbinlog|mysql によるデータベースのリストアにも影響を及ぼすことがある。

あらゆるケースでこの問題を回避する最も簡単な方法は、このような非決定論的なクエリに ORDER BY 節を追加して、レコードが常に同じ順序で格納/変更されるようにすることである。今後の MySQL バージョンでは、必要に応じて自動的に ORDER BY 節が追加されるようにする予定である。

テンポラリテーブルを使用して解決する必要があるクエリで RPAD 関数、または最終的に右側に空白を追加する他の文字列関数を使用した場合、すべての結果文字列で右側の空白が削除される。次に、このクエリの例を示す。

SELECT RPAD(t1.field1, 50, ' ') AS f2, RPAD(t2.field2, 50, ' ') AS f1 FROM table1 as t1 LEFT JOIN table2 AS t2 ON t1.record=t2.joinID ORDER BY t2.record;

このバグの最終的な結果は、生成されるフィールドの右側の空白を取得できなくなることである。

この動作は、すべてのバージョンの MySQL に見られる。

この原因は、テンポラリテーブルとして最初に使用される HEAP テーブルで VARCHAR 型のカラムを処理できないことである。

この動作は、4.1 シリーズのいずれかのリリースで修正される予定である。

テーブル定義ファイルの格納方法のために、テーブル名、カラム名、または列挙に文字 255（CHAR(255)）を使用することができない。これは、新しいテーブル定義ファイル形式が導入されるバージョン 5.1 で修正される予定である。

SET CHARACTER SET を使用した場合、データベース名、テーブル名、およびカラム名で変換された文字を使用することができない。

LIKE ... ESCAPE で ESCAPE とともに _ または % を使用することができない。

DECIMAL 型のカラムにさまざまな形式（+01.00、1.00、01.00）で数字が格納されている場合、GROUP BY によって各値が異なる値として見なされることがある。

WHERE なしで DELETE FROM merge_table を使用すると、テーブルに対するマッピングのみが消去され、マップされたテーブルの内容は一切削除されない。

MIT-pthreads を使用した場合、別のディレクトリにサーバを構築することができない。これには MIT-pthreads の変更が必要なので、これを修正する予定はない。 See 項2.3.6. 「MIT-pthreads に関する注意事項」。

GROUP BY、ORDER BY、または DISTINCT で BLOB 値を ``確実に'' 使用することができない。これらの場合に BLOB 値を比較した場合、最初の max_sort_length バイト（デフォルトは 1024）のみが使用される。これは、mysqld の -O max_sort_length オプションを使用して変更することができる。ほとんどの場合の回避策は、SELECT DISTINCT LEFT(blob,2048) FROM tbl_name のように部分文字列を使用することである。

BIGINT または DOUBLE で計算が実行される（通常はどちらの長さも 64 ビット）。取得する精度は関数によって異なる。一般的なルールとして、ビット関数は BIGINT 精度、IF および ELT() は BIGINT または DOUBLE 精度、残りは DOUBLE 精度で実行される。ビットフィールド以外については、符号なしの長い値が 63 ビット（9223372036854775807）より大きい値に解決される場合、そのような値を使用しないようにする必要がある。MySQL サーバ 4.0 では、3.23 に比べて BIGINT の処理が向上している。

BLOB 型および TEXT 型のカラムを除くすべての文字列カラムで、取得時に後続のスペースすべてが自動的に削除される。CHAR 型の場合、これには問題はなく、SQL-92 に準拠した機能と見なすことができる。バグは、MySQL サーバで VARCHAR 型のカラムが同様に処理される点である。

1 つのテーブルに ENUM 型および SET 型のカラムを 255 個までしか作成することができない。

MySQL では現在、MIN()、MAX()、およびその他の集約関数において、ENUM 型と SET 型のカラムがセット内の文字列の相対的な位置ではなく、文字列値によって比較される。

mysqld_safe によって、mysqld から mysqld ログにすべてのメッセージがリダイレクトされる。これに関する 1 つの問題として、mysqladmin refresh を実行してログを閉じた後、もう一度開いた場合、stdout および stderr が引き続き元のログにリダイレクトされる点がある。--log を広範に使用する場合、'hostname'.log ではなく 'hostname'.err にログが記録されるように mysqld_safe を編集して、元のログを削除し、mysqladmin refresh を実行することで、元のログのスペースを簡単に解放できるようにする必要がある。

UPDATE ステートメントで、カラムが左から右に更新される。更新されたカラムを参照した場合、元の値ではなく更新された値を取得する。たとえば、次のようなコマンドがあるとする。

mysql> UPDATE tbl_name SET KEY=KEY+1,KEY=KEY+1;

この場合、KEY は 1 ではなく、2 によって更新される。

1 つのクエリで複数のテンポラリテーブルを参照することができるが、特定のテンポラリテーブルを複数回参照することはできない。たとえば、次のクエリは動作しない。

mysql> SELECT * FROM temporary_table, temporary_table AS t2;

RENAME が、TEMPORARY テーブル、または MERGE テーブル内で使用されているテーブルで動作しない。

結合で '非表示の' カラムを使用している場合と使用していない場合とで、オプティマイザによって DISTINCT が異なって処理されることがある。結合では、非表示のカラムは結果の一部としてカウントされるが（表示されていない場合も同様）、通常のクエリでは、非表示のカラムは DISTINCT 比較に関連しない。DISTINCT を実行した場合も非表示のカラムが比較されないように、今後これを変更する予定である。

この例は以下のとおりである。

SELECT DISTINCT mp3id FROM band_downloads
       WHERE userid = 9 ORDER BY id DESC;

および

SELECT DISTINCT band_downloads.mp3id
       FROM band_downloads,band_mp3
       WHERE band_downloads.userid = 9
       AND band_mp3.id = band_downloads.mp3id
       ORDER BY band_downloads.id DESC;

2 番目の例の場合、MySQL サーバ 3.23.x では、結果セットで 2 つの同じレコードを取得することがある（非表示の id カラムが異なる場合があるため）。

この問題は、結果に ORDER BY カラムがないクエリのみで発生する。これは、SQL-92 では許可されていない。

MySQL サーバではトランザクションをサポートしないためにデータをロールバックすることができないテーブル型を使用することができるので、MySQL サーバと他の SQL サーバでは動作が多少異なる。これは単に、MySQL サーバでは SQL コマンドに対してロールバックが実行されないようにするためである。これは、アプリケーションでカラム値をチェックする必要があるときには多少不便な場合があるが、他の方法では非常に困難な最適化を MySQL サーバで実行することができるので、実質的には速度が大幅に向上する。

カラムを正しくない値に設定した場合、ロールバックが行われる代わりに、カラムに取りうる値のうち最適な値が格納される。

空のセットを返すクエリで PROCEDURE を実行した場合、PROCEDURE によってカラムが変換されないことがある。

MERGE 型のテーブルを作成する際に、基になるテーブルの型に互換性があるかどうかがチェックされない。

MySQL サーバではまだ、NaN、-Inf、および Inf 値を倍精度で処理することができない。これらを使用した場合、データをエクスポートおよびインポートしようとすると問題が発生する。中間的な解決策として、NaN を NULL（可能な場合）、-Inf および Inf をそれぞれ使用可能な最小および最大倍精度値に変更する必要がある。

ALTER TABLE を使用して MERGE テーブルで使用されているテーブルに UNIQUE インデックスを追加した後、ALTER TABLE を使用して MERGE テーブルに通常のインデックスを追加すると、一意でない古いキーがテーブルに存在していた場合、テーブルでキーの順序が変わる。これは、重複キーをできるだけ早く検出できるように、ALTER TABLE が UNIQUE キーを通常のキーの前に配置するためである。

LOCK TABLES を使用してロックされている多数のテーブルのうちの 1 つのテーブルで DROP TABLE を実行した場合、ハングスレッドを取得することがある。

以下の場合、コアダンプを取得することがある。

MySQL サーババージョン 3.23.2 より前は、同じキーで WHERE を使用してキーを更新した UPDATE でエラーが発生することがあった。これは、そのキーがレコードの検索に使用され、同じレコードが複数回検出されることがあったためである。次に例を示す。

UPDATE tbl_name SET KEY=KEY+1 WHERE KEY > 100;

回避策は次のとおりである。

mysql> UPDATE tbl_name SET KEY=KEY+1 WHERE KEY+0 > 100;

これが機能するのは、MySQL サーバでは WHERE 節内の式にインデックスが使用されないためである。

MySQL サーババージョン 3.23 より前は、すべての数値型が固定小数点型フィールドとして扱われていた。そのため、固定小数点型フィールドの小数部桁数を指定しなければならなかった。すべての結果が、正確な小数部桁数で返されていた。