| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
MySQL (R) ソフトウェアによって、非常に高速で堅牢なマルチスレッド形式のマルチユーザ SQL（Structured Query Language）データベースサーバが実現します。MySQL サーバは、ミッションクリティカルで負荷が高い運用システムにも、大規模に展開されるソフトウェアへの組み込みにも対応するように設計されています。MySQL は、MySQL AB の商標です。
MySQL ソフトウェアはデュアルライセンス製品です。ユーザは、GNU 一般公衆利用許諾契約書（http://www.fsf.org/licenses/ ）の条件に基づいてオープンソース/フリーソフトウェア製品として MySQL ソフトウェアを使用することも、MySQL AB から標準の商用ライセンスを購入することもできます。 「1.4 MySQL のサポートとライセンス」 節 参照 。
MySQL の Web サイト（http://www.mysql.com/ ）には、MySQL ソフトウェアに関する最新情報が掲載されています。
このマニュアルで特に興味深いセクションは以下のとおりです。
MySQL データベースサーバの背景にある会社に関する情報については、 「1.3 MySQL AB の概要」 を参照。
MySQL データベースサーバの機能に関する説明については、 「1.2.2 MySQL の主な機能」 を参照。
MySQL Database Software の移植に関するヒントについては、 「E. 他システムへの移植」 を参照。
MySQL データベースサーバのチュートリアルについては、 「3. MySQL チュートリアル」 を参照。
SQL のサンプルとベンチマーク情報については、ベンチマークディレクトリ（ディストリビューションの `sql-bench'）を参照。
重要:
エラー（多くの場合、バグと呼ばれます）の報告は、質問やコメントと同様に、通常の MySQL メーリングリストにお送りください。 「1.7.1.1 MySQL メーリングリスト」 節 参照 。 「1.7.1.3 バグまたは問題を報告する方法」 節 参照 。
Unix では、mysqlbug スクリプトを使用してバグレポートを生成します（Windows ディストリビューションについては、basedir にファイル `mysqlbug.txt' があります。このファイルをバグレポートのテンプレートとして使用してください）。
ソースディストリビューションについては、mysqlbug スクリプトは `scripts' ディレクトリにあります。バイナリディストリビューションについては、mysqlbug は `bin' ディレクトリ（MySQL サーバ RPM パッケージの場合は `/usr/bin'）にあります。
MySQL サーバで重大なセキュリティバグを見つけた場合は、security@mysql.com に電子メールをお送りください。
| 1.1 このマニュアルについて | ||
| 1.2 MySQL データベース管理システムの概要 | ||
| 1.3 MySQL AB の概要 | ||
| 1.4 MySQL のサポートとライセンス | ||
| 1.5 MySQL の開発ロードマップ | ||
| 1.6 MySQL の今後（TODO） | ||
| 1.7 MySQL の情報源 | ||
| 1.8 MySQL の標準への準拠 |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
これは、MySQL のリファレンスマニュアルです。バージョン 4.1.1-alpha の MySQL について記述しています。機能に関する変更は常に、バージョンに言及して説明しています。そのため、古いバージョンの MySQL ソフトウェア（3.23 または 4.0 製品版など）を使用している場合でも、このマニュアルは参考になります。バージョン 5.0（開発版）のリファレンスもあります。
これはリファレンスマニュアルなので、SQL やリレーショナルデータベースの概念に関する一般的な説明は記載していません。
MySQL データベースソフトウェア は継続して開発が行われているので、マニュアルも頻繁に更新されます。このマニュアルの最新版は、http://www.mysql.com/documentation/ から HTML、PDF、Windows HLP 版などのさまざまな形式で入手することができます。
元の文書は Texinfo ファイルです。HTML 版は、変更された texi2html を使用して自動的に生成されます。プレーンテキスト版と Info 版は、makeinfo を使用して生成されます。PostScript 版は、texi2dvi と dvips を使用して生成されます。PDF 版は、pdftex を使用して生成されます。
マニュアル内で情報を見つけるのが困難な場合は、http://www.mysql.com/doc/ にある検索可能なバージョンを試してみてください。
このマニュアルへの追加や修正に関する提案は、マニュアルチーム（docs@mysql.com ）にお送りください。
このマニュアルは当初、David Axmark と Michael (Monty) Widenius によって執筆されました。現在は、Arjen Lentz、Paul DuBois、および Stefan Hinz で構成される MySQL マニュアルチームによって管理されています。その他多数の貢献者については、 「C. 協力者」 を参照してください。
このマニュアルの著作権（2003）は、スウェーデンの会社 MySQL AB が所有しています。 「1.4.2 MySQL で使用されている著作権とライセンス」 節 参照 。
| 1.1.1 このマニュアルの表記規則 |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
このマニュアルは、以下の表記規則に従って記載されています。
constant
mysqladmin の動作を確認するには、--help オプションを指定して呼び出す。"
特定のプログラムからコマンドを実行する必要があることを示す場合、コマンドの前にプログラムとプロンプトを記述します。たとえば、shell> はログインシェルから実行するコマンドを示し、mysql> は mysql クライアントプログラムから実行するコマンドを示します。
shell> シェルコマンド mysql> mysql コマンド |
"シェル" はコマンドインタープリタです。Unix では通常、sh や csh などのプログラムです。Windows では、Windows コンソールで通常実行される command.com や cmd.exe です。
シェルコマンドは、Bourne シェル構文を使用して表します。csh 形式のシェルを使用している場合は、多少異なるコマンドを発行しなければならないことがあります。たとえば、環境変数を設定し、コマンドを実行するシーケンスは、Bourne シェル構文では次のようになります。
shell> VARNAME=value some_command |
csh または tcsh の場合は、このシーケンスを次のように実行します。
shell> setenv VARNAME value shell> some_command |
データベース名、テーブル名、およびカラム名は多くの場合、コマンドに代入する必要があります。このような代入が必要であることを示す場合、このマニュアルでは db_name、tbl_name、および col_name を使用します。たとえば、次のようなステートメントがあるとします。
mysql> SELECT col_name FROM db_name.tbl_name; |
これは、同様のステートメントを入力する場合、データベース名、テーブル名、およびカラム名を自分で指定することを意味します。たとえば、次のようになります。
mysql> SELECT author_name FROM biblio_db.author_list; |
SQL キーワードは大文字と小文字を区別しないので、大文字で記述されることも小文字で記述されることもあります。ただし、このマニュアルでは大文字を使用します。
構文の説明で省略可能な単語や節を表す場合、角かっこ（`[' および `]'）を使用します。たとえば、次のステートメントでは、IF EXISTS は省略可能です。
DROP TABLE [IF EXISTS] tbl_name |
構文要素が複数の選択候補で構成される場合、それらの候補を縦線（`|'）で区切ります。選択候補のいずれかを選択できる場合は、次のように、それらの候補を角かっこ（`[' および `]'）内に列挙します。
TRIM([[BOTH | LEADING | TRAILING] [remstr] FROM] str) |
選択候補のいずれかを選択しなければならない場合は、次のように、それらの候補を中かっこ（`{' および `}'）内に列挙します。
{DESCRIBE | DESC} tbl_name {col_name | wild}
|
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
MySQL は最もよく知られているオープンソース SQL データベース管理システムで、MySQL AB によって開発、提供、サポートが行われています。MySQL AB は MySQL の開発者によって創設された営利会社で、MySQL データベース管理システムに関連するサービスを提供することでビジネスを構築しています。 「1.3 MySQL AB の概要」 節 参照 。
MySQL の Web サイト（http://www.mysql.com/ ）には、MySQL ソフトウェアと MySQL AB に関する最新情報が掲載されています。
MySQL はデータベース管理システムである。
データベースは、構造化されたデータの集合である。データベースには、簡単なショッピングリストから絵画のギャラリー、または社内ネットワークの膨大な量の情報など、さまざまなものがある。コンピュータデータベースに格納されているデータに対して追加、アクセス、および処理などを行うには、MySQL サーバのようなデータベース管理システムが必要となる。コンピュータは大量のデータの処理に非常に優れているので、データベース管理システムは、スタンドアロンのユーティリティまたは他のアプリケーションの一部として、データ処理の中心的な役割を果たす。
リレーショナルデータベースでは、1 つの大きな保管領域にすべてのデータが格納されるのではなく、個別のテーブルにデータが格納される。これにより、速度と柔軟性が向上する。"MySQL" の SQL は "Structured Query Language" を表す。SQL はデータベースへのアクセスに使用される最も一般的な標準化言語で、ANSI/ISO SQL 標準によって定義されている（SQL 標準は 1986 年以降開発が繰り返され、複数のバージョンがある。このマニュアルでは、"SQL-92" は 1992 年にリリースされた標準、"SQL-99" は 1999 年にリリースされた標準、"SQL:2003" は 2003 年半ばにリリース予定の標準を表す。"SQL 標準" という用語は、任意の時点における現行バージョンの SQL 標準を表す場合に使用する）。
オープンソースである。
オープンソースとは、だれもがそのソフトウェアを使用し、変更できることを意味する。MySQL ソフトウェアは、だれもが無料でインターネットからダウンロードし、使用することができる。必要に応じて、ソースコードを調べ、ニーズに合わせて変更することができる。MySQL ソフトウェアでは、GPL（GNU 一般公衆利用許諾契約書（http://www.fsf.org/licenses/ ））に基づいて、さまざまな状況でのソフトウェアの使用において許可されている事項と禁止されている事項が規定されている。GPL では不都合な場合や商用アプリケーションに MySQL コードを組み込む必要がある場合は、商用ライセンス版を購入することができる。 「1.4.3 MySQL ライセンス」 節 参照 。
MySQL データベースサーバ は、非常に高速で信頼性があり、簡単に使用することができる。それを求めていたのなら、ぜひ試していただきたい。また、MySQL サーバには、ユーザと密接に協力して開発された実用的な機能が備わっている。ベンチマークページで、他のデータベース管理システムと MySQL サーバのパフォーマンスを比較することができる。 「5.1.4 MySQL ベンチマークスィート」 節 参照 。
MySQL サーバは当初、既存のソリューションよりもはるかに速く大規模なデータベースを処理することを目的として開発され、多くを要求される運用環境で数年間にわたって使用されている。引き続き開発が行われているが、MySQL サーバは現在、便利で多彩な機能を備えている。その接続性、速度、安全性によって、MySQL サーバはインターネット上のデータベースへのアクセスに非常に適している。
詳細な技術情報については、 「6. MySQL SQL言語リファレンス」 を参照。MySQL データベースソフトウェア は、さまざまなバックエンドをサポートするマルチスレッド形式の SQL サーバ、複数の異なるクライアントプログラムおよびライブラリ、管理ツール、幅広いアプリケーションプログラミングインタフェース（API）から成るクライアント/サーバシステムである。
また、MySQL サーバはアプリケーションへのリンクが可能なマルチスレッドライブラリとして提供されており、さらに小規模で高速な、管理しやすい製品を作り出すことができる。
必要なアプリケーションや言語ですでに MySQL データベースサーバがサポートされていると思われる。
MySQL の正式な発音は "My Ess Que Ell" ですが（"my sequel" ではありません）、"my sequel" と発音したり、ローカライズされた他の方法で発音してもかまいません。
| 1.2.1 MySQL の歴史 | ||
| 1.2.2 MySQL の主な機能 | ||
| 1.2.3 MySQL の安定性 | ||
| 1.2.4 MySQL テーブルの最大サイズ | ||
| 1.2.5 西暦 2000 年対応 |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
当初は、高速で低レベルな独自の（ISAM）ルーチンを使用してテーブルに接続するために mSQL を使用するつもりでした。しかし、いくつかのテストを行った結果、mSQL はそれほど高速でも柔軟でもないため、ニーズに合わないという結論に至りました。これが要因となって、私たちのデータベースへの新しい SQL インタフェースを開発することになりました。ただし、mSQL とほとんど同じ API インタフェースを使用することにしました。この API を選択したのは、mSQL で使用するために記述されたサードパーティのコードを MySQL で使用するために簡単に移植できるようにするためです。
MySQL という名前の由来は明らかではありません。当社の基本ディレクトリおよび多数のライブラリやツールには、10 年以上にわたって "my" というプリフィックスが使われています。また、共同創設者 Monty Widenius の娘の名前も My です。そのため、このうちのどちらが MySQL の名前の由来となったのかは、私たちにとってもいまだに謎なのです。
MySQL のイルカ（当社のロゴ）の名前は Sakila です。Sakila は、当社の「イルカのネーミング」コンテストで、ユーザによって提案された膨大な数の名前の中から MySQL AB の創設者が選んだものです。この名前を提案したのは、アフリカのスワジランド出身の Ambrose Twebaze というオープンソースソフトウェアの開発者でした。Ambrose によると、Sakila という名前は、スワジランドの現地語であるシスワティ語にルーツがあるということです。また、Sakila は、Ambrose の出生国であるウガンダに近い、タンザニアのアルーシャにある町の名前でもあります。
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
MySQL データベースソフトウェア の重要な特徴の一部を以下で説明します。 「1.5.1 MySQL 4.0 の概要」 節 参照 。
MyISAM）を使用している。
MySQL コードは Purify（市販のメモリリーク検出システム）と Valgrind と呼ばれる GPL ツール（http://developer.kde.org/~sewardj/ ）を使用してテストされている。
FLOAT、DOUBLE、CHAR、VARCHAR、TEXT、BLOB、DATE、TIME、DATETIME、TIMESTAMP、YEAR、SET、および ENUM 型。 「6.2 カラム型」 節 参照 。
SELECT 節および WHERE 節での演算子と関数の完全なサポート。たとえば、次のように使用することができる。
mysql> SELECT CONCAT(first_name, " ", last_name)
-> FROM tbl_name
-> WHERE income/dependents > 10000 AND age > 30;
|
GROUP BY 節および ORDER BY 節の完全なサポート。グループ関数（COUNT()、COUNT(DISTINCT ...)、AVG()、STD()、SUM()、MAX()、MIN()、および GROUP_CONCAT()）のサポート。
LEFT OUTER JOIN および RIGHT OUTER JOIN のサポート。
DELETE、INSERT、REPLACE、および UPDATE は、変更された（影響を受けた）レコードの数を返す。サーバに接続する際にフラグを設定することで、代わりに一致したレコードの数を返すことも可能である。
MySQL 固有の SHOW コマンドを使用すると、データベース、テーブル、およびインデックスに関する情報を取得することができる。EXPLAIN コマンドを使用すると、オプティマイザによるクエリの解決方法を決定することができる。
ABS は有効なカラム名である。関数呼び出しで、関数名とその後に続く `(' との間にスペースを使用できない点が唯一の制限事項である。 「6.1.7 MySQL での予約語の扱い」 節 参照 。
MySQL サーバを使用して 50,000,000 レコードが格納されたデータベースを処理している。また、MySQL サーバを使用して 60,000 テーブル、約 5,000,000,000 レコードを処理しているユーザもいる。
MySQL サーバのコンパイル時に変更可能である）。インデックスでは、CHAR 型または VARCHAR 型のカラムのプリフィックスを使用することができる。
MySQL サーバに接続することができる。NT ファミリ（NT、2000、または XP） の Windows システムでは、クライアントは名前付きパイプを使用して接続することができる。Unix システムでは、Unix ドメインソケットファイルを使用して接続することができる。
MySQL サーバに接続することができる。クライアントは、Windows と Unix のどちらで実行されていてもかまわない。Connector/ODBC ソースが使用可能である。他の多くの機能と同様に、ODBC 2.5 のすべての機能がサポートされる。 「11.2 MySQL の ODBC サポート」 節 参照 。
MySQL サーバの起動時に変更することができる。非常に高度なソートの例については、チェコ語のソートコードを参照。MySQL サーバではさまざまなキャラクタセットがサポートされており、コンパイル時および実行時に指定することができる。
mysqlcheck クライアントを介してコマンドラインから使用可能である。また、MySQL には、MyISAM テーブルでこれらの操作を実行するための myisamchk という非常に高速なコマンドラインユーティリティが組み込まれている。 「4. データベース管理」 節 参照 。
--help または -? オプションを指定して呼び出すと、すべての MySQL プログラムでオンラインヘルプを参照することができる。
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
このセクションでは、"MySQL サーバの安定性" と "プロジェクトにおける MySQL サーバの信頼性" という問題を扱います。これらの問題を明らかにし、多数の潜在ユーザに関連する重要な質問に答えます。このセクションに記載されている情報は、問題の特定や使用方法の報告が非常に活発に行われているメーリングリストから収集したデータに基づいています。
元のコードは 1980 年代初期に記述されたもので、安定したコードベースとなっています。また、ISAM テーブル形式には下位互換性が維持されています。MySQL AB の前身である TcX では、1996 年半ば以来、MySQL コードはプロジェクトで問題なく動作していました。MySQL データベースソフトウェア がより広く一般にリリースされるとすぐに、新しいユーザが "テストされていないコード" をいくつか見つけました。それ以降の新しいリリースごとに、移植性に関する問題は少なくなっています（また一方では、新しいリリースごとに多数の新機能が追加されています）。
MySQL サーバの各リリースは常に実用的です。問題が発生するのは、ユーザが "グレーゾーン" のコードを使用しようとしたときだけです。もっとも、新しいユーザはグレーゾーンとは何かを知りません。そのため、このセクションでは、現時点で認識されているその領域を説明します。説明は主に、MySQL サーバのバージョン 3.23 および 4.0 を対象とします。最新バージョンでは、バグセクションに記載されている設計関連のバグを除き、報告されている既知のバグはすべて修正されています。 「1.8.6 MySQL の既知のエラーと設計上の問題」 節 参照 。
MySQL サーバは、複数層の独立したモジュールで構成されています。新しいモジュールの一部とそれらのテストステータスを以下に示します。
MySQL 4.x では、拡張されたレプリケーション機能に対する取り組みが引き続き行われている。
InnoDB テーブル -- 安定（3.23.49 以降の 3.23）
InnoDB トランザクションストレージエンジンは、MySQL 3.23 ツリーのバージョン 3.23.49 以降で安定していると宣言されている。InnoDB は、大規模で負荷が高い運用システムで使用されている。
BDB テーブル -- ガンマ
Berkeley DB コードは非常に安定しているが、MySQL サーバでは引き続き BDB トランザクションストレージエンジンインタフェースの改良を行っている。そのため、他のテーブル型のように十分にテストされるにはしばらく時間が必要である。
MySQL 4.0 には、重要な拡張機能が実装されている。
MyODBC 3.51 （ODBC SDK 3.51 を使用） -- 安定
MyISAM テーブルの自動リカバリ -- ガンマ
MyISAM ストレージエンジンの新しいコードのみに該当する。このコードでは、テーブルを開く際に、前にそのテーブルが正しく閉じられたかどうかがチェックされ、正しく閉じられていない場合はテーブルの自動チェック/修復が実行される。
MySQL 4.0 における MyISAM テーブルの新機能である。
fcntl()）を使用することに大きな問題がある。このような場合、--skip-external-locking フラグを指定して mysqld を実行する必要がある。問題は、一部の Linux システムと、NFS によってマウントされたファイルシステム使用時の SunOS で発生することが確認されている。
MySQL AB では、高品質のサポートを有料でお客様に提供しております。また、だれもが質問することができるコミュニティリソースとして MySQL メーリングリストを提供しております。
バグは通常、パッチによって至急修正されます。重大なバグについては、ほとんどの場合、新しいリリースが提供されます。
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
MySQL バージョン 3.22 では、テーブルのサイズは 4 GB（4 ギガバイト）に制限されていました。MySQL バージョン 3.23 の MyISAM テーブル型では、テーブルの最大サイズが 800万テラバイト（2^63 バイト）に増えました。有効なテーブルのサイズがこのように大きくなったことで、現在では、MySQL データベースに効果的なテーブルの最大サイズは通常、MySQL 内部の制限ではなく、オペレーティングシステムのファイルサイズに関する制限によって決まります。
次の表は、オペレーティングシステムのファイルサイズに関する制限の例を示しています。
| オペレーティングシステム | ファイルサイズの制限 |
| Linux-Intel 32-bit | 2 GB、LFS 使用の場合はそれ以上 |
| Linux-Alpha | 8 TB（?） |
| Solaris 2.5.1 | 2 GB（パッチにより 4GB まで可） |
| Solaris 2.6 | 4 GB（フラグにより変更可能） |
| Solaris 2.7 Intel | 4 GB |
| Solaris 2.7 UltraSPARC | 512 GB |
Linux 2.2 では、ext2 ファイルシステム用の LFS パッチを使用することで、2 GB より大きいサイズのテーブルを使用することができます。また、Linux 2.4 には ReiserFS および ext3 が組み込まれており、これらを使用することで大きいファイルがサポートされます。現在の Linux ディストリビューションのほとんどはカーネル 2.4 に基づいており、必要な Large File Support（LFS）パッチすべてがすでに組み込まれています。しかし、それでも、有効な最大ファイルサイズはいくつかの要因によって左右されます。そのうちの 1 つが、MySQL テーブルを格納するために使用されるファイルシステムです。
Linux における LFS の詳細については、Andreas Jaeger の「Large File Support in Linux」（http://www.suse.de/~aj/linux_lfs.html ）を参照してください。
デフォルトでは、MySQL では有効な最大サイズが約 4 GB の内部構造を持つ MyISAM テーブルが作成されます。SHOW TABLE STATUS コマンドまたは myisamchk -dv table_name を使用して、テーブルの最大サイズをチェックすることができます。 「4.6.8 SHOW 構文」 節 参照 。
4 GB より大きいサイズのテーブルが必要な場合（オペレーティングシステムで大規模ファイルがサポートされていれば）、CREATE TABLE ステートメントで AVG_ROW_LENGTH および MAX_ROWS オプションを指定することができます。4 GB を超えるテーブルを作成するには、これらのオプションを使用してください。 「6.5.3 CREATE TABLE 構文」 節 参照 。また、ALTER TABLE を使用して、後でこれらのオプションを設定することもできます。 「6.5.4 ALTER TABLE 構文」 節 参照 。
MyISAM テーブルのファイルサイズに関する制限に対処する方法として、他に次のような方法があります。
myisampack を使用してテーブルを圧縮することができる。myisampack では通常、テーブルが少なくとも 50% 圧縮されるので、結果的にはるかに大きいテーブルを使用することが可能である。また、myisampack を使用して、複数のテーブルを 1 つのテーブルにマージすることもできる。 「4.8.4 myisampack（MySQL 圧縮読み取り専用テーブルジェネレータ）」 節 参照 。
MyISAM データファイルに関するオペレーティングシステムのファイル制限に対処する方法として、RAID オプションを使用することもできる。 「6.5.3 CREATE TABLE 構文」 節 参照 。
MySQL に組み込まれている MERGE ライブラリを使用して、同一のテーブルの集合を 1 つのテーブルとして処理することもできる。 「7.2 MERGE テーブル」 節 参照 。
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
MySQL サーバ自体は、西暦 2000 年（Y2K）対応に関しては何の問題もありません。
MySQL サーバでは、TIMESTAMP 値については日付を 2037 年に処理する Unix 時間関数を使用する。DATE 値および DATETIME 値については、9999 年までの日付が使用可能である。
MySQL 日付関数すべてが 1 つのファイル `sql/time.cc' に格納され、西暦 2000 年に対応するように非常に慎重にコード化されている。
MySQL バージョン 3.22 以降では、YEAR 型のカラムに 0 年および 1901 年から 2155 年までの年を 1 バイトで格納し、2 桁または 4 桁で表示することができる。2 桁の年はすべて、1970 年から 2069 年までの範囲にあると見なされる。つまり、YEAR 型のカラムに 01 を格納した場合、MySQL サーバでは 2001 として処理される。
次の簡単な例で、MySQL サーバに 2030 年までの日付に関する問題がないことを示します。
mysql> DROP TABLE IF EXISTS y2k;
Query OK, 0 rows affected (0.01 sec)
mysql> CREATE TABLE y2k (date DATE,
-> date_time DATETIME,
-> time_stamp TIMESTAMP);
Query OK, 0 rows affected (0.00 sec)
mysql> INSERT INTO y2k VALUES
-> ("1998-12-31","1998-12-31 23:59:59",19981231235959),
-> ("1999-01-01","1999-01-01 00:00:00",19990101000000),
-> ("1999-09-09","1999-09-09 23:59:59",19990909235959),
-> ("2000-01-01","2000-01-01 00:00:00",20000101000000),
-> ("2000-02-28","2000-02-28 00:00:00",20000228000000),
-> ("2000-02-29","2000-02-29 00:00:00",20000229000000),
-> ("2000-03-01","2000-03-01 00:00:00",20000301000000),
-> ("2000-12-31","2000-12-31 23:59:59",20001231235959),
-> ("2001-01-01","2001-01-01 00:00:00",20010101000000),
-> ("2004-12-31","2004-12-31 23:59:59",20041231235959),
-> ("2005-01-01","2005-01-01 00:00:00",20050101000000),
-> ("2030-01-01","2030-01-01 00:00:00",20300101000000),
-> ("2050-01-01","2050-01-01 00:00:00",20500101000000);
Query OK, 13 rows affected (0.01 sec)
Records: 13 Duplicates: 0 Warnings: 0
mysql> SELECT * FROM y2k;
+------------+---------------------+----------------+
| date | date_time | time_stamp |
+------------+---------------------+----------------+
| 1998-12-31 | 1998-12-31 23:59:59 | 19981231235959 |
| 1999-01-01 | 1999-01-01 00:00:00 | 19990101000000 |
| 1999-09-09 | 1999-09-09 23:59:59 | 19990909235959 |
| 2000-01-01 | 2000-01-01 00:00:00 | 20000101000000 |
| 2000-02-28 | 2000-02-28 00:00:00 | 20000228000000 |
| 2000-02-29 | 2000-02-29 00:00:00 | 20000229000000 |
| 2000-03-01 | 2000-03-01 00:00:00 | 20000301000000 |
| 2000-12-31 | 2000-12-31 23:59:59 | 20001231235959 |
| 2001-01-01 | 2001-01-01 00:00:00 | 20010101000000 |
| 2004-12-31 | 2004-12-31 23:59:59 | 20041231235959 |
| 2005-01-01 | 2005-01-01 00:00:00 | 20050101000000 |
| 2030-01-01 | 2030-01-01 00:00:00 | 20300101000000 |
| 2050-01-01 | 2050-01-01 00:00:00 | 00000000000000 |
+------------+---------------------+----------------+
13 rows in set (0.00 sec)
|
TIMESTAMP 型のカラムの最後の値がゼロになっているのは、最後の年（2050）が TIMESTAMP の上限を超えているためです。TIMESTAMP データ型は現在の時刻を格納するために使用され、32 ビットマシンでは 19700101000000 から 20300101000000 までの値（符号付きの値）をサポートします。64 ビットマシンでは、2106 までの値（符号なしの値）を処理します。
この例は、DATE および DATETIME データ型にも日付の使用に関する問題がないことを示しています。これらのデータ型では、9999 年までの日付が処理されます。
MySQL サーバ自体は Y2K に対応していますが、Y2K に対応していないアプリケーションとともに使用すると、問題が発生することがあります。たとえば、多くの古いアプリケーションでは、4 桁の値ではなく、あいまいな 2 桁の値を使用して年の格納や処理が行われます。この問題は、値が "ない" ことを示す場合に 00 や 99 などの値を使用するアプリケーションでは、さらに複雑になる可能性があります。それぞれのアプリケーションはさまざまなプログラマによって記述されており、プログラマごとに異なる規則や日付処理関数を使用している可能性があるので、これらの問題を修正するのは困難な場合があります。
そのため、MySQL サーバに Y2K 問題がなくても、アプリケーションとしてあいまいでない情報を提供することが必要です。年を表す 2 桁の値を含むあいまいな日付入力データの処理に関する MySQL サーバのルールについては、 「6.2.2.1 西暦 2000 年問題と日付型」 を参照してください。
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
MySQL AB は MySQL の創始者と主な開発者の会社で、最初は David Axmark、Allan Larsson、および Michael "Monty" Widenius によってスウェーデンに創設されました。
MySQL サーバの開発者はすべて、当社の従業員です。当社は、世界中の多数の国の人々から成るバーチャルな組織です。毎日ネットを使って相互に、またはユーザ、サポータ、およびパートナと広くコミュニケーションを図っています。
当社は、MySQL ソフトウェアの開発と新しいユーザへの当社のデータベースの普及に専念しております。MySQL AB は、MySQL のソースコード、MySQL のロゴと商標、およびこのマニュアルの著作権を所有しています。 「1.2 MySQL データベース管理システムの概要」 節 参照 。
| 1.3.1 MySQL AB のビジネスモデルとサービス | ||
| 1.3.2 問い合わせ先 |
MySQL の本質的価値が、MySQL およびオープンソースへの当社の献身を示しています。
当社は、MySQL データベースソフトウェア が次のようなものであることを願っています。
MySQL AB と MySQL AB の従業員は、以下のことを心がけています。
オープンソースの理念を推進し、オープンソースコミュニティをサポートする。
MySQL の Web サイト（http://www.mysql.com/ ）には、MySQL と MySQL AB に関する最新情報が掲載されています。
会社名の "AB" の部分は、スウェーデン語の "aktiebolag"、つまり "株式会社" の頭字語です。したがって、"MySQL 株式会社" という意味です。実際、MySQL AB の子会社として、MySQL Inc. や MySQL GmbH などがあります。これらの子会社はそれぞれ、アメリカとドイツにあります。
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
当社に最もよく寄せられる質問の 1 つが "製品を無償で提供してどのように採算をとっているのですか?" というものです。これに対する回答は次のとおりです。
MySQL AB は、サポート、サービス、商用ライセンス、およびロイヤルティで利益を上げています。当社では、これらの収益を製品開発や MySQL ビジネスの拡大に充てています。
| 1.3.1.1 サポート | ||
| 1.3.1.2 トレーニングと検定 | ||
| 1.3.1.3 コンサルティング | ||
| 1.3.1.4 商用ライセンス | ||
| 1.3.1.5 パートナ提携 |
当社は、創設以来、常に利益を上げています。2001 年 10 月には、代表的な北欧の投資家と何人かの資金援助者から事業投資を受けました。この投資は、当社のビジネスモデルを固め、継続的な成長の基盤を確立するために使われています。
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
MySQL AB は、MySQL データベースの創始者と主な開発者が所有し、経営しています。開発者は、お客様やその他のユーザのニーズや問題を常に把握しておくために、サポートの提供に取り組んでいます。当社のサポートはすべて、経験豊富な開発者によって提供されます。実際、難しい質問には、MySQL サーバの最も重要な作成者である Michael Monty Widenius が回答します。 「1.4.1 MySQL AB によって提供されるサポート」 節 参照 。
詳細とさまざまなレベルのサポートの申し込みについては、http://www.mysql.com/support/ を参照するか、当社の販売スタッフ（sales@mysql.com ）にお問い合わせください。
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
MySQL AB は、MySQL 関連のトレーニングを世界中で実施しています。当社では、オープンコースと企業固有のニーズに合わせた社内トレーニング用コースの両方を用意しております。また、当社のパートナである MySQL 認定トレーニングセンターによる MySQL トレーニングもあります。
当社のトレーニング教材には、当社のマニュアルで使用されているものと同じサンプルデータベースやサンプルアプリケーションが使用されています。また、教材は最新版の MySQL を反映するように常に更新されています。さらに、当社の講師は開発チームによってサポートされているため、トレーニングの質とコース教材の継続的な開発を保証いたします。また、トレーニング中に発生した質問には必ずお答えします。
トレーニングコースに参加することで、MySQL アプリケーションの目標を達成することができます。さらに、以下のことを実現することができます。
MySQL 検定の準備をする。
受講者として、またはトレーニングパートナとして当社のトレーニングに関心をお持ちの方は、トレーニングセクション（http://www.mysql.com/training/ ）を参照するか、当社（training@mysql.com ）にお問い合わせください。
MySQL 検定プログラムの詳細については、http://www.mysql.com/certification/ を参照してください。
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
MySQL AB とその認定パートナは、世界中の MySQL サーバユーザおよび独自のソフトウェアに MySQL サーバを組み込むユーザにコンサルティングサービスを提供しています。
当社のコンサルタントは、データベースの設計と調整、効率的なクエリの作成、最適なパフォーマンスを確保するためのプラットフォームの調整、移行に関する問題の解決、レプリケーションの設定、堅牢なトランザクションアプリケーションの構築などをお手伝いします。また、大規模展開を目的として、独自の製品やアプリケーションに MySQL サーバを組み込むお客様のお手伝いもいたします。
当社のコンサルタントは、開発チームと密接に協力しています。そのため、専門的なサービスの技術的な品質を保証いたします。コンサルティングは、2 日間のパワースタートセッションから、何週間、何か月にもわたるプロジェクトまでさまざまです。当社の専門家は、MySQL サーバだけを扱うわけではありません。PHP や Perl などのプログラミング言語およびスクリプト言語についても対応します。
コンサルティングサービスおよびコンサルティングパートナに関心をお持ちの方は、当社の Web サイトのコンサルティングセクション（http://www.mysql.com/consulting/ ）を参照するか、コンサルティングスタッフ（consulting@mysql.com ）にお問い合わせください。
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
MySQL データベースは、GNU 一般公衆利用許諾契約書（GPL）に基づいてリリースされています。つまり、MySQL ソフトウェアは、GPL の下、無償で使用することができます。ただし、GPL の条件（アプリケーションも GPL に基づいていなければならないという要件など）に拘束されたくない場合は、MySQL AB から同じ製品の商用ライセンスを購入することができます。http://www.mysql.com/products/pricing.html を参照してください。MySQL AB は MySQL のソースコードの著作権を所有しているので、デュアルライセンスを採用して、GPL および商用ライセンスの下で同じ製品を提供することができます。これにより、オープンソースへの MySQL AB の取り組みに影響が生じることはありません。商用ライセンスが必要な場合の詳細については、 「1.4.3 MySQL ライセンス」 を参照してください。
当社は、MySQL サーバに価値を追加するサードパーティのオープンソース GPL ソフトウェアの商用ライセンスも販売しております。わかりやすい例として、ACID サポート、行レベルのロック、クラッシュリカバリ、マルチバージョニング、外部キーサポートなどを提供する InnoDB トランザクションストレージエンジンがあります。 「7.5 InnoDB テーブル」 節 参照 。
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
MySQL AB には、トレーニングコース、コンサルティングとサポート、出版、MySQL および関連製品の再販と提供を扱う世界的なパートナプログラムがあります。MySQL AB パートナは Web サイト（http://www.mysql.com/ ）で公開されるとともに、個々の製品を区別し、ビジネスを促進するために特殊なバージョンの MySQL の商標を使用する権利を得られます。
MySQL AB パートナに関心をお持ちの方は、partner@mysql.com に電子メールをお送りください。
MySQL という言葉と MySQL のイルカのロゴは、MySQL AB の商標です。 「1.4.4 MySQL AB のロゴと商標」 節 参照 。これらの商標は、MySQL の創始者が何年にもわたって築いてきた意義深い価値を表しています。
MySQL の Web サイト（http://www.mysql.com/ ）は、開発者やユーザによく知られています。2001 年 10 月には、1,000 万回のページアクセスがありました。当社の Web サイトへの訪問者は、ソフトウェアとハードウェアの両方について購入の決定と推奨を行うグループです。訪問者の 12% が正式に購入を決定し、購入の決定にまったく関連しないのはわずか 9% です。65% を超える訪問者が過去半年以内に 1 件以上のオンライン取り引きを行ったことがあり、70% の訪問者はその後数か月内に取り引きを予定しています。
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
MySQL の Web サイト（http://www.mysql.com/ ）には、MySQL と MySQL AB に関する最新情報が掲載されています。
当社のニュースリリース（http://www.mysql.com/news/ ）に掲載されていないプレス関連のサービスや質問については、press@mysql.com に電子メールをお送りください。
MySQL AB と有効なサポート契約を結んでいる方は、MySQL ソフトウェアに関する技術的な質問に対する明確な回答をタイムリーに得ることができます。詳細については、 「1.4.1 MySQL AB によって提供されるサポート」 を参照してください。または、Web サイトの http://www.mysql.com/support/ を参照するか、sales@mysql.com に電子メールをお送りください。
MySQL トレーニングについては、トレーニングセクション（http://www.mysql.com/training/ ）を参照してください。インターネットにアクセスできない場合は、MySQL AB のトレーニングスタッフ（training@mysql.com ）に電子メールでお問い合わせください。 「1.3.1.2 トレーニングと検定」 節 参照 。
MySQL 検定プログラムについては、http://www.mysql.com/certification/ を参照してください。 「1.3.1.2 トレーニングと検定」 節 参照 。
コンサルティングに関心をお持ちの方は、Web サイトのコンサルティングセクション（http://www.mysql.com/consulting/ ）を参照してください。インターネットにアクセスできない場合は、MySQL AB のコンサルティングスタッフ（consulting@mysql.com ）に電子メールでお問い合わせください。 「1.3.1.3 コンサルティング」 節 参照 。
https://order.mysql.com/ では、商用ライセンスをオンラインで購入することができます。また、MySQL AB に FAX で購入申込書を送信する方法を参照することもできます。ライセンスの詳細については、http://www.mysql.com/products/pricing.html を参照してください。ライセンスに関する質問がある場合やハイボリュームライセンス契約の見積もりが必要な場合は、Web サイト（http://www.mysql.com/ ）にある問い合わせ用紙に記入するか、licensing@mysql.com （ライセンスに関する質問）または sales@mysql.com （販売見積もり）に電子メールをお送りください。 「1.4.3 MySQL ライセンス」 節 参照 。
MySQL AB とのパートナ提携に関心をお持ちの企業は、partner@mysql.com に電子メールをお送りください。 「1.3.1.5 パートナ提携」 節 参照 。
MySQL の商標ポリシーの詳細については、http://www.mysql.com/company/trademark.html を参照するか、trademark@mysql.com に電子メールをお送りください。 「1.4.4 MySQL AB のロゴと商標」 節 参照 。
採用セクション（http://www.mysql.com/company/jobs/ ）に掲載されている MySQL AB の職種に関心をお持ちの方は、jobs@mysql.com に電子メールをお送りください。履歴書は、添付ファイルとして送信するのではなく、電子メールメッセージの最後にプレーンテキスト形式で記載してください。
多数のユーザ間の一般的なディスカッションについては、該当するメーリングリストを参照してください。 「1.7.1 MySQL メーリングリスト」 節 参照 。
エラー（多くの場合、バグと呼ばれます）の報告は、質問やコメントと同様に、通常の MySQL メーリングリストにお送りください。 「1.7.1.1 MySQL メーリングリスト」 節 参照 。MySQL サーバで重大なセキュリティバグを見つけた場合は、security@mysql.com に電子メールをお送りください。 「1.7.1.3 バグまたは問題を報告する方法」 節 参照 。
公開可能なベンチマーク結果をお持ちの方は、benchmarks@mysql.com に電子メールでお問い合わせください。
このマニュアルへの追加や修正に関する提案については、マニュアルチーム（docs@mysql.com ）に電子メールをお送りください。
MySQL の Web サイト（http://www.mysql.com/ ）の運営や内容に関する質問やコメントについては、webmaster@mysql.com に電子メールをお送りください。
MySQL AB にはプライバシーポリシーがあります。http://www.mysql.com/company/privacy.html を参照してください。このポリシーに関する質問については、privacy@mysql.com に電子メールをお送りください。
その他の質問についてはすべて、info@mysql.com に電子メールをお送りください。
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
このセクションでは、MySQL のサポートおよびライセンスに関する取り決めについて説明します。
| 1.4.1 MySQL AB によって提供されるサポート | ||
| 1.4.2 MySQL で使用されている著作権とライセンス | ||
| 1.4.3 MySQL ライセンス | ||
| 1.4.4 MySQL AB のロゴと商標 |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
MySQL AB からのテクニカルサポートでは、MySQL データベースエンジンをコード化するソフトウェアエンジニアからお客様個々の問題に応じた回答が提供されます。
当社は、テクニカルサポートを広く、包括的にとらえます。お客様にとって重要な MySQL ソフトウェアに関するほとんどの問題は、当社にとっても重要です。ユーザは通常、さまざまなコマンドやユーティリティを使用する方法、パフォーマンスボトルネックを除去する方法、クラッシュしたシステムをリストアする方法、MySQL に対するオペレーティングシステムやネットワークの影響を理解する方法、バックアップおよびリカバリに関するベストプラクティスを設定する方法、API を利用する方法などについてのヘルプを必要としています。当社のサポートは、できる限りのお手伝いをすることを心がけていますが、MySQL サーバと独自のユーティリティのみを対象とし、MySQL サーバにアクセスするサードパーティ製品は対象としておりません。
さまざまなサポートオプションの詳細については、http://www.mysql.com/support/ を参照してください。ここでは、サポート契約をオンラインで申し込むこともできます。インターネットにアクセスできない場合は、販売スタッフ（sales@mysql.com ）に電子メールでお問い合わせください。
テクニカルサポートは生命保険のようなものです。生命保険がなくても何年間も快適に暮らせますが、そのときがくれば、非常に重要になります。しかし、それから保険に入ったのでは遅すぎるのです。重要なアプリケーションに MySQL サーバを使用している場合、問題が突然発生したときに、自分だけですべてを解決するのは非常に時間がかかります。そのような場合、MySQL AB で採用している経験豊富な MySQL のトラブルシューティング担当者への直接のアクセスが必要になることがあります。
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
MySQL AB は、MySQL のソースコード、MySQL のロゴと商標、およびこのマニュアルの著作権を所有しています。 「1.3 MySQL AB の概要」 節 参照 。MySQL ディストリビューションには、さまざまなライセンスが関連しています。
mysqlclient ライブラリ、クライアント、および GNU readline ライブラリ内の MySQL 固有のソースはすべて、GNU 一般公衆利用許諾契約書の対象である。 「H. GNU General Public License」 節 参照 。このライセンスのテキストは、ディストリビューションのファイル `COPYING' にある。
GNU getopt ライブラリは、GNU 劣等一般公衆利用許諾契約書の対象である。http://www.fsf.org/licenses/ を参照。
regexp ライブラリ）の一部は、Berkeley スタイルの著作権の対象である。
MySQL の古いバージョン（3.22 以前）には、さらに厳密なライセンス（http://www.mysql.com/products/mypl.html ）が適用される。個々のバージョンのマニュアルを参照。
MySQL のリファレンスマニュアルは現在、GPL スタイルのライセンス下では提供されていない。このマニュアルの使用には、以下の条件が適用される。
MySQL AB からの書面による事前の合意が必要である。
MySQL ライセンスの施行については、 「1.4.3 MySQL ライセンス」 を参照してください。 「1.4.4 MySQL AB のロゴと商標」 も参照してください。
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
MySQL ソフトウェアは、最もよく知られていると思われるオープンソースライセンスである GNU 一般公衆利用許諾契約書（GPL）に基づいてリリースされています。GPL ライセンスの正式な条件については、http://www.fsf.org/licenses/ を参照してください。http://www.fsf.org/licenses/gpl-faq.html および http://www.gnu.org/philosophy/enforcing-gpl.html も参照してください。
MySQL ソフトウェアは GPL に基づいてリリースされているので、多くの場合、無償で使用することができます。ただし、特定の用途については、https://order.mysql.com/ で MySQL AB から商用ライセンスを購入しなければならない場合があります。詳細については、http://www.mysql.com/products/licensing.html を参照してください。
MySQL の古いバージョン（3.22 以前）には、さらに厳密なライセンス（http://www.mysql.com/products/mypl.html ）が適用されます。個々のバージョンのマニュアルを参照してください。
商用ライセンス、GPL、または古い MySQL ライセンスに基づいて MySQL ソフトウェアを使用しても、MySQL AB の商標を使用する権利が自動的に与えられるわけではないことに注意してください。 「1.4.4 MySQL AB のロゴと商標」 節 参照 。
| 1.4.3.1 商用ライセンスに基づく MySQL ソフトウェアの使用 | ||
| 1.4.3.2 GPL に基づく MySQL ソフトウェアの無償使用 |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
GPL ライセンスは、プログラムが GPL プログラムにリンクしている場合、作成された製品のすべての部分のソースコードもすべて GPL に基づいてリリースする必要があるという意味で、伝染性があります。この GPL 要件に従わない場合、ライセンス条件に違反することとなり、GPL プログラムを使用する権利をすべて失います。また、損害を受ける危険を冒すことにもなります。
以下のような場合、商用ライセンスが必要です。
MySQL ソフトウェアの GPL コードとプログラムをリンクし、商用製品を作成するため、または追加した非 GPL コードを他の理由でクローズソースにするために、作成する製品に GPL に基づくライセンスを付与しない場合。商用ライセンスを購入すると、MySQL ソフトウェアを使用する際に、同じコードでも GPL が適用されなくなる。
MySQL ソフトウェアのみを使用する非 GPL アプリケーションを提供し、MySQL ソフトウェアとともに出荷する場合。このタイプのソリューションは、ネットワーク経由で行われてもリンクしていると見なされる。
GPL ライセンスの下で必要とされるソースコードの提供を行わずに、MySQL ソフトウェアのコピーを提供する場合。
MySQL データベースの今後の開発をサポートする場合。MySQL AB からサポートを直接購入することは、MySQL ソフトウェアの開発に貢献するもう 1 つのよい方法である。また、ユーザにも直接メリットがある。 「1.4.1 MySQL AB によって提供されるサポート」 節 参照 。
ライセンスを要求する場合、MySQL ソフトウェアの各インストールに 1 つずつ必要です。これは、1 台のマシン上の CPU の数には関係ありません。また、サーバに接続するクライアントの数に理論上の制限はありません。
商用ライセンスについては、当社の Web サイト（http://www.mysql.com/products/licensing.html ）を参照してください。サポート契約については、http://www.mysql.com/support/ を参照してください。特殊なニーズがある場合やインターネットにアクセスできない場合は、販売スタッフ（sales@mysql.com ）に電子メールでお問い合わせください。
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
GPL の条件に従っている場合、GPL の下で MySQL ソフトウェアを無償で使用することができます。GPL に関する一般的な質問に対する回答などの詳細については、Free Software Foundation の一般的な FAQ（http://www.fsf.org/licenses/gpl-faq.html ）を参照してください。一般に、以下のような場合に GPL を使用します。
GPL に基づく MySQL のソースコードの両方を製品とともに提供する場合。
MySQL システムにリンクしていない、または MySQL システムに依存していない他のプログラムとバンドルされた MySQL のソースコードを提供する場合。これは、GPL ライセンスでは単に集約と呼ばれる。
MySQL システムのいずれの部分も提供しない場合、無償で使用することができる。
MySQL サーバを使用した Web ホスティングを顧客に提供する場合。当社は、MySQL サポートがある ISP を使用するように推奨している。これは、MySQL のインストールに関して発生しうる問題を解決するためのリソースが、実際にそれらの ISP にあるという信頼感が得られるためである。ISP に MySQL サーバの商用ライセンスがなくても、適切なパッチが適用されていることを確認できるように、顧客に少なくとも MySQL インストールのソースへの読み取りアクセス権を付与する必要がある。
MySQL データベースソフトウェアを Web サーバとともに使用する場合（提供する製品でない限り）、商用ライセンスは不要である。MySQL サーバを使用する市販の Web サーバを実行する場合も、同様である。これは、MySQL システムのいずれの部分も提供しないためである。ただし、この場合、MySQL ソフトウェアによって企業がサポートされているので、MySQL サポートを購入していただくよう希望する。
MySQL データベースソフトウェアの使用に商用ライセンスが不要な場合でも、MySQL AB からサポートを購入することをお勧めします。これにより、MySQL の開発に貢献することになるとともに、お客様自身も直接メリットが得られます。 「1.4.1 MySQL AB によって提供されるサポート」 節 参照 。
MySQL データベースソフトウェアの使用によって利益を得るような商用コンテキストで MySQL データベースソフトウェアを使用する場合は、いずれかのレベルのサポートを購入することで MySQL ソフトウェアの開発のお手伝いをお願いしています。MySQL データベースがお客様のビジネスに役立っているのなら、今度はお客様が MySQL AB に手を貸してください（そうでないと、サポートに関する質問をする場合、多くの労力を要した成果を無償で使用しているだけでなく、当社に無償でサポートを提供するように依頼していることにもなります）。
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
Web サイト、書籍、またはボックス製品に MySQL AB のイルカのロゴを掲載したいという MySQL データベースユーザが多数いらっしゃいます。当社はこれを歓迎し、推奨しておりますが、MySQL という言葉と MySQL のイルカのロゴは MySQL AB の商標であり、http://www.mysql.com/company/trademark.html に記載されている当社の商標ポリシーに従って使用する必要があることに注意してください。
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
MySQL のイルカのロゴは、2001 年にフィンランドの広告代理店 Priority によってデザインされたものです。頭がよく、敏捷でスリムな動物なので、データの大海原を楽々と進むということから、MySQL データベースに適したシンボルとしてイルカが選ばれました。また、私たちもイルカが好きでした。
MySQL のオリジナルロゴを使用できるのは、MySQL AB の代表者と、書面による合意によって使用が許可されたユーザのみです。
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
当社は、Web サイト（http://www.mysql.com/press/logos.html ）からダウンロードし、MySQL AB からの書面による許可なしにサードパーティの Web サイトで使用できる特殊な条件付き使用ロゴをデザインしております。これらのロゴの使用にはまったく制限はありませんが、名前のとおり、当社の商標ポリシーが適用されます。商標ポリシーも、Web サイトで参照することができます。ロゴを使用する場合は、商標ポリシーをよくお読みください。基本的な条件は以下のとおりです。
MySQL の商標を掲載するサイトの作成者および所有者が MySQL AB ではなく、ユーザ自身であることを明確にする。
MySQL AB や MySQL AB の商標の価値にマイナスとなるような使い方をしない。当社は、MySQL AB の商標の使用権を無効にする権利を留保している。
GPL に基づく MySQL データベースを使用する場合、アプリケーションはオープンソースであると同時に、MySQL サーバに接続可能でなければならない。
ニーズに合わせた特別な調整に関する質問については、trademark@mysql.com に電子メールでお問い合わせください。
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
以下の場合、MySQL のロゴを使用するには、MySQL AB からの書面による許可が事前に必要となります。
MySQL AB のロゴを掲載する場合
MySQL AB のロゴを Web サイトやその他の場所に掲載する場合
法律上および商業上の理由から、当社は、製品や書籍などにおける MySQL の商標の使用を監視します。通常、商用製品に MySQL AB のロゴを掲載する場合には料金をいただきます。収益の一部が MySQL データベースの今後の開発資金として使用されるのが適切だと考えるためです。
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
MySQL のパートナシップロゴを使用できるのは、MySQL AB と書面によるパートナシップ契約を結んでいる企業および個人のみです。パートナシップには、MySQL の講師またはコンサルタントとしての認定も含まれます。詳細については、 「1.3.1.5 パートナ提携」 を参照してください。
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
MySQL という言葉の使用
MySQL AB は MySQL データベースの参照を歓迎しますが、MySQL という言葉は MySQL AB の商標であることに注意してください。そのため、テキスト内で MySQL という言葉を最初に使用する箇所や最も目立つように使用する箇所には商標記号（TM）を添え、必要に応じて、MySQL が MySQL AB の商標であることを記載する必要があります。詳細については、商標ポリシー（http://www.mysql.com/company/trademark.html ）を参照してください。
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
MySQL という言葉の使用
製品名、企業名、またはインターネットドメイン名に MySQL という言葉を使用する場合は、MySQL AB からの書面による許可が必要です。
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
このセクションでは、MySQL 4.0、4.1、5.0、および 5.1 で実装または計画されている主な機能を含む、MySQL の開発ロードマップのスナップショットを提供します。バージョンシリーズごとの情報については、以下のセクションを参照してください。次の表は、最も要望があった機能の一部についての計画をまとめたものです。
| 機能 | MySQL バージョン |
| UNION | 4.0 |
| サブクエリ | 4.1 |
| R-tree | 4.1（MyISAM テーブル用） |
| ストアドプロシージャ | 5.0 |
| ビュー | 5.0 または 5.1 |
| カーソル | 5.0 |
| 外部キー | 5.1（InnoDBについては 3.23 で実装済み） |
| トリガ | 5.1 |
| Full OUTER JOIN | 5.1 |
| 制約 | 5.1 |
| 1.5.1 MySQL 4.0 の概要 | ||
| 1.5.2 MySQL 4.1 の概要 | ||
| 1.5.3 MySQL 5.0、次期開発リリース |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
ユーザが長い間待ち望んでいた MySQL サーバ 4.0 が運用ステータスで使用可能になりました。
MySQL 4.0 は、http://www.mysql.com/ および当社のミラーからダウンロードすることができます。MySQL 4.0 は多数のユーザによってテストされ、多数の大規模サイトで運用されています。
MySQL サーバ 4.0 の主な新機能は、当社の既存のビジネスおよびコミュニティユーザ向けに設計されており、ミッションクリティカルで負荷が高いデータベースシステムに対応したソリューションとして MySQL データベースソフトウェアを拡張します。組み込みデータベースのユーザを対象とした新機能もあります。
MySQL 4.0 は、2003 年 3 月にリリースされたバージョン 4.0.12 で、運用について安定していると宣言されました。そのため、今後、4.0 シリーズについてはバグ修正のみが行われ、古い 3.23 シリーズについては重大なバグ修正のみが行われることになります。 「2.5.2 バージョン 3.23 から 4.0 へのアップグレード」 節 参照 。
すでに使用可能な MySQL 4.1（アルファバージョン）には、MySQL ソフトウェアの新機能が追加されます。 「1.5.2 MySQL 4.1 の概要」 節 参照 。
| 1.5.1.1 MySQL 4.0 で使用可能な機能 | ||
| 1.5.1.2 組み込み MySQL サーバ |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
INSERT ステートメント、パックされたインデックスの検索、FULLTEXT インデックスの作成、および COUNT(DISTINCT) など、いくつかの領域で MySQL サーバの速度がさらに向上している。
InnoDB ストレージエンジンが MySQL サーバの標準機能として提供されるようになった。つまり、ACID トランザクションの完全サポート、連鎖 UPDATE および DELETE を使用した外部キー、および行レベルのロックが標準機能となっている。 「7.5 InnoDB テーブル」 節 参照 。
FULLTEXT 検索機能によって、大きいテキストの FULLTEXT インデックスが、バイナリと自然言語の両方の検索ロジックで作成可能になった。最小ワード長をカスタマイズし、任意の自然言語で独自のストップワード一覧を定義することができるため、MySQL サーバ上に新しいアプリケーションセットを構築することができる。 「6.8 MySQL 全文検索」 節 参照 。
TRUNCATE TABLE がある。
UNION ステートメントがサポートされるようになった。これは、多数のユーザが長い間待ち望んでいた標準の SQL 機能である。
MySQL で新しいキャラクタセット latin1_de がサポートされるようになり、ドイツ語のソート順では、ウムラウトを含む単語がドイツの電話帳と同じ順序でソートされる。
mysqld パラメータ（スタートアップオプション）が、サーバを停止しなくても設定できるようになった。これは、データベース管理者（DBA）にとって便利な機能である。 「5.5.6 SET 構文」 節 参照 。
DELETE および UPDATE ステートメントが追加された。
MyISAM ストレージエンジンにテーブルレベルの（以前のようにデータベースレベルのみではない）シンボリックリンクのサポートが追加された。また、Windows では、データベースレベルにおけるシンボリックリンクの処理がデフォルトで有効である。
SQL_CALC_FOUND_ROWS と FOUND_ROWS() を使用すると、LIMIT 節を含む SELECT クエリがその節を含めない場合に返すレコードの数を調べることができる。
このマニュアルのニュースセクションに、機能の詳細な一覧があります。 「D.3 Changes in release 4.0.x (Production)」 節 参照 。
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
libmysqld によって、MySQL サーバはアプリケーションの大規模展開に対応します。組み込み MySQL サーバライブラリを使用すると、さまざまなアプリケーションや電子機器に MySQL サーバを組み込むことができます。それらのアプリケーションや電子機器のエンドユーザには、実際はそれらの基になっているデータベースがあるということはわかりません。組み込み MySQL サーバは、インターネット機器、パブリックキオスク、ハードウェアとソフトウェアが組み合わさったターンキー装置、高性能インターネットサーバ、CD-ROMで配布されている独立言語型データベースなどの背後での使用に最適です。
libmysqld の多くのユーザは、MySQL のデュアルライセンスの恩恵を受けます。GPL に拘束されたくないユーザは、商用ライセンスに基づいてソフトウェアを使用することもできます。組み込み MySQL ライブラリでは通常のクライアントライブラリと同じインタフェースが使用されているので、使いやすく、便利です。 「11.1.15 組み込み MySQL サーバライブラリ libmysqld」 節 参照 。
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
MySQL サーバ 4.0 は、サブクエリや Unicode などの新機能（バージョン 4.1 で実装）および SQL-99 ストアドプロシージャの開発（バージョン 5.0 で実装）の基礎となっています。これらの機能は、当社のお客様からの要望が最も高いものです。
これらの追加機能によって、MySQL データベースサーバの批評家は、MySQL データベース管理システムの問題を指摘する際に、これまで以上に想像力が必要になります。その安定性、速度、使いやすさですでによく知られている MySQL サーバは、非常に多くを望む購入者の条件リストを満たすことができます。
| 1.5.2.1 MySQL 4.1 で使用可能な機能 | ||
| 1.5.2.2 段階的ロールアウト | ||
| 1.5.2.3 即時の開発用途への対応 |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
このセクションに記載されている機能は、MySQL 4.1 に実装されています。MySQL 4.1 には、他にも計画されている機能があります。 「1.6.1 4.1 で計画されている新機能」 節 参照 。
ストアドプロシージャなど、コード化されるほとんどの新機能は MySQL 5.0 で使用できるようになります。 「1.6.2 5.0 で計画されている新機能」 節 参照 。
SELECT ステートメントである。派生テーブル（名前のないビュー）とは、別のステートメントの FROM 節内のサブクエリである。 「6.4.2 サブクエリ構文」 節 参照 。
HEAP テーブルについて B-TREE インデックスの作成がサポートされるようになり、正確でない検索の応答時間が大幅に短縮される。
CREATE TABLE table_name2 LIKE table_name1 を使用することで、既存のテーブルとまったく同じ構造の新しいテーブルを 1 つのステートメントで作成することができる。
SHOW WARNINGS は、最後のコマンドの警告を表示する。 「4.6.8.9 SHOW WARNINGS | ERRORS」 節 参照 。
utf8 および ucs2 キャラクタセットによる幅広い Unicode サポートが提供されるようになった。
HELP コマンドを追加した。サーバ側でこの情報を取得できるメリットは、情報が常にその特定のサーババージョンに該当する点である。この情報は SQL ステートメントを発行することで参照できるので、任意のクライアントをそれにアクセスするように記述することができる。たとえば、mysql コマンドラインクライアントはこの機能を使用できるように変更されている。
INSERT ... ON DUPLICATE KEY UPDATE ... 構文が実装された。この構文を使用すると、INSERT によって PRIMARY または UNIQUE キー（インデックス）で重複が発生した場合に既存のレコードを更新することができる。 「6.4.3 INSERT 構文」 節 参照 。
GROUP_CONCAT() を実装した。この関数によって、グループ化されたレコードのカラムを 1 つの結果文字列に連結する非常に便利な機能が追加される。 「6.3.7 GROUP BY 節で使用する関数と修飾子」 節 参照 。
このマニュアルのニュースセクションに、機能の詳細な一覧があります。 「D.2 Changes in release 4.1.x (Alpha)」 節 参照 。
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
MySQL 4.1 には、新しい機能が追加されます。アルファバージョンは、すでにダウンロードすることができます。 「1.5.2.3 即時の開発用途への対応」 節 参照 。
バージョン 4.1 に追加される機能は、ほとんど確定しています。すでに、バージョン 5.0 に向けて新たな開発が行われています。MySQL 4.1 はアルファ（さらに新機能が追加/変更される可能性がある段階）、ベータ（機能が固定され、バグ修正のみが行われる段階）、ガンマ（製品版としてのリリースを数週間後に控えた段階）というステップをたどります。このプロセスの最後に、MySQL 4.1 は新しい製品版となります。
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
現在、MySQL 4.1 はアルファ段階にあり、http://www.mysql.com/downloads/mysql-4.1.html でバイナリリリースをダウンロードすることができます。すべてのバイナリリリースは、テストするプラットフォームでエラーが発生することなく、一連の広範なテストに合格しています。 「D.2 Changes in release 4.1.x (Alpha)」 節 参照 。
MySQL 4.1 の最新の開発ソースの使用を希望するユーザのために、4.1 BitKeeper リポジトリを公開しています。 「2.3.4 開発ソースツリーからのインストール」 節 参照 。
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
MySQL の新たな開発は、ストアドプロシージャなどの新機能を特徴とする 5.0 リリースに焦点が置かれています。 「1.6.2 5.0 で計画されている新機能」 節 参照 。
MySQL 開発の最前線の参照を希望するユーザのために、MySQL バージョン 5.0 の BitKeeper リポジトリを公開しています。 「2.3.4 開発ソースツリーからのインストール」 節 参照 。
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
| 1.6.1 4.1 で計画されている新機能 | ||
| 1.6.2 5.0 で計画されている新機能 | ||
| 1.6.3 5.1 で計画されている新機能 | ||
| 1.6.4 近い将来に計画されている新機能 | ||
| 1.6.5 中期的な将来に計画されている新機能 | ||
| 1.6.6 計画されていない新機能 |
このセクションでは、MySQL サーバに実装予定の機能の概要を説明します。一覧はバージョンごとに分かれており、項目はほぼ、実装される順序に並んでいます。
注意: 特定の機能を至急必要とする企業レベルのユーザは、支援オプションについて sales@mysql.com にお問い合わせください。スポンサー企業からの特定の目的に絞った資金提供によって、その目的のために特別なリソースを割り当てることができます。過去に資金提供を受けた機能の例として、レプリケーションがあります。
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
以下の機能は、MySQL 4.1 にまだ実装はされていませんが、MySQL 4.1 がベータ段階に移行する前に実装される予定です。MySQL 4.1 にすでに実装されている機能の一覧については、 「1.5.2.1 MySQL 4.1 で使用可能な機能」 を参照してください。
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
MySQL 5.0 には、以下の機能が組み込まれる予定です。多数の開発者がさまざまなプロジェクトで作業しているので、他にも多くの機能があることに注意してください。これらの機能の一部は、MySQL 4.1 に追加される可能性もあります。MySQL 4.1 にすでに実装されている機能の一覧については、 「1.5.2.1 MySQL 4.1 で使用可能な機能」 を参照してください。
MySQL 開発の最前線の参照を希望するユーザのために、MySQL バージョン 5.0 の BitKeeper リポジトリを公開しています。 「2.3.4 開発ソースツリーからのインストール」 節 参照 。
MyISAM テーブルでインデックスが R-TREE インデックスとして作成されるように明示的に指定する機能。4.1 では、地理データ（GIS データ型）について R-TREE インデックスが内部で使用されるが、必要に応じて作成することはできない。
HEAP テーブルの可変長レコード。
VARCHAR の完全なサポート（255 を超えるカラム長、後続のスペースを削除しない）の追加（MyISAM ストレージエンジンではすでにこれがサポートされているが、ユーザレベルではまだ使用できない）。
SHOW COLUMNS FROM table_name（カラム名の表示を可能にするために mysql クライアントによって使用される）によって、テーブルではなく定義ファイルのみが開くようにする。これによって、使用されるメモリが少なくて済むとともに、速度がはるかに向上する。
MyISAM テーブルの DELETE でレコードキャッシュを使用できるようにする。そのためには、`.MYD' ファイルを更新する際にスレッドレコードキャッシュを更新する必要がある。
HEAP）テーブルの改良。
SET CHARACTER SET を使用する場合、文字列だけでなく、クエリ全体が一度に変換されるようにする必要がある。これによって、ユーザはデータベース名、テーブル名、およびカラム名で変換された文字を使用できるようになる。
MERGE テーブルで使用されているテーブルに対して RENAME TABLE を発行した場合にテーブルが破損する可能性がある問題の解決。
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
FOREIGN KEY のサポート。
BIT 型を最適化する（現在、BIT は 1 バイトを必要とし、TINYINT のシノニムとして扱われている）。
RENAME DATABASE を実装する。すべてのストレージエンジンについてこれを安全にするには、以下のように動作する必要がある。
RENAME コマンドを使用して行われるように、すべてのテーブルについて、別のデータベースへのテーブルの名前変更を行う。
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
CONNECT BY PRIOR ...。
SUM(DISTINCT) を追加する。
INSERT SQL_CONCURRENT および mysqld --concurrent-insert。
UPDATE TABLE foo SET @a=a+b,a=@a, b=@a+c のように、UPDATE ステートメントでの変数の更新を有効にする。
SELECT id, @a:=COUNT(*), SUM(sum_col)/@a FROM table_name GROUP BY id のように GROUP BY とともに使用できるように変更する。
TIMESTAMP および AUTO_INCREMENT フィールドを更新しないように LOAD DATA INFILE に IMAGE オプションを追加する。
LOAD DATA INFILE ... UPDATE 構文を追加する。
LOAD DATA INFILE ... REPLACE INTO として処理される。
LOAD DATA INFILE で次のような構文が認識されるようにする。
LOAD DATA INFILE 'file_name.txt' INTO TABLE tbl_name
TEXT_FIELDS (text_field1, text_field2, text_field3)
SET table_field1=CONCAT(text_field1, text_field2),
table_field3=23
IGNORE text_field3
|
SET 型のカラムを使用する新しい関数。
ADD_TO_SET(value,set)
REMOVE_FROM_SET(value,set)
mysql を停止する場合、別の接続を開き、実行中の元のクエリを終了する必要がある。または、サーバでこれが検出されるようにする必要がある。
SHOW INFO FROM tbl_name が実装される。
SELECT a FROM table_name1 LEFT JOIN table_name2 USING (a) を有効にする。この場合、a は、table_name1 テーブルに由来すると想定される。
UPDATE ステートメントの DELETE および REPLACE オプション（これによって、更新時に重複キーエラーが発生した場合、レコードが削除されるようになる）。
DATETIME の書式を変更する。
DEFAULT 値が追加されないようにする。DEFAULT がないカラムについては、INSERT ステートメントに値がない場合、エラーを生成する。
ANY()、EVERY()、および SOME() グループ関数を追加する。標準の SQL では、これらはブール型のカラムのみで動作するが、0 値を FALSE、0 以外の値を TRUE として処理することで、あらゆるカラム/式で動作するように拡張することができる。
MAX(column) の型をカラム型と同じになるように固定する。
mysql> CREATE TABLE t1 (a DATE); mysql> INSERT INTO t1 VALUES (NOW()); mysql> CREATE TABLE t2 SELECT MAX(a) FROM t1; mysql> SHOW COLUMNS FROM t2; |
MyISAM リカバリが実行されないようにする。
INSERT ... SELECT を変更する。
pread()/pwrite() のシミュレーションを追加して、同時挿入を有効にする。
SELECT MIN(column) ... GROUP BY の実行時に、元のフィールド型を返す。
long_query_time をマイクロ秒単位で詳細に指定できるようにする。
PACK または COMPRESS 操作を実行できるように、myisampack コードをサーバにリンクする。
INSERT/DELETE/UPDATE 時にテンポラリキーバッファキャッシュを追加する。
ALTER TABLE を実行する場合、そのディスクにテンポラリテーブルを作成する。
DATE/DATETIME 型を実装する。
MyISAM など）をコンパイルできるように、configure を固定する。
LIMIT @a,@b のように、SQL 変数を LIMIT の引数として使用できるようにする。
mysql から Web ブラウザへの自動出力。
LOCK DATABASES（およびさまざまなオプション）。
SHOW STATUS によって表されるさまざまな数値。レコードの読み取りおよび更新。1 つのテーブルに対する SELECT および結合を使用した SELECT。 SELECT されたテーブルの平均数。ORDER BY および GROUP BY クエリの数。
mysqladmin copy database new-database。このためには、COPY 操作を mysqld に追加する必要がある。
SHOW HOSTS。
NULL にテーブル名を変更する。
SELECT COUNT(*)*(id+0) FROM table_name GROUP BY id の場合、数字 -> 文字列 -> 数字という変換を避けるために、数値に対して Item_copy_string を使用しない。
INSERT DELAYED を実行するクライアントが ALTER TABLE によって停止されないように変更する。
UPDATE 節でカラムが参照されている場合、更新が開始される前の古い値がカラムに含まれるように固定する。
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
get_changed_tables(timeout,table1,table2,...) を実装する。
SET TIMESTAMP=#; を使用して更新ログにタイムスタンプを追加する。
col_name=n が見つかると、定数 n の場合、式内の他の col_name を n に置換する。現時点では、単純なケースのみでこれが行われている。
MINUS、INTERSECT、および FULL OUTER JOIN（現時点では、UNION（4.0）と LEFT|RIGHT OUTER JOIN がサポートされている）。
SQL_OPTION MAX_SELECT_TIME=# を使用できるようにする。
LIMIT を拡張する。
mysqld_safe に対する変更には注意が必要である。Debian が準拠しようとしている FSSTND に従って、PID ファイルは `/var/run/<progname>.pid' に、ログファイルは `/var/log' に格納される必要がある。"pidfile" および "log" の最初の宣言に "DATADIR" を挿入すると、これらのファイルの場所を 1 つのステートメントで変更することができるので、便利である。
gzip によって圧縮されたファイルをステートメントで読み込めるように、LOAD DATA INFILE に zlib() の使用を追加する。
BLOB 型のカラムのソートおよびグループ化を固定する（現時点では、部分的に解決されている）。
JOIN の完全サポートを追加する。
GET_LOCK() で複数のロックを取得できるようにする。これを実行した場合、この変更によって発生する可能性があるデッドロックも処理する必要がある。
時間は、実際の時間ではなく、作業量に基づいて記されています。
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
SQL-92/SQL-99 への完全な準拠を目標としています。実装を計画していない機能はありません。
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
| 1.7.1 MySQL メーリングリスト | ||
| 1.7.2 IRC（インターネットリレーチャット）の MySQL コミュニティサポート |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
| 1.7.1.1 MySQL メーリングリスト | ||
| 1.7.1.2 質問またはバグの報告 | ||
| 1.7.1.3 バグまたは問題を報告する方法 | ||
| 1.7.1.4 メーリングリストで質問に回答する際のガイドライン |
このセクションでは MySQL メーリングリストの概要を説明するとともに、リストの使用方法に関するガイドラインを提供します。メーリングリストを購読すると、リストへのすべての投稿が電子メールメッセージとして送信されます。また、自分の質問や回答をリストに送信することもできます。
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
このセクションに記載されているメーリングリストを購読する場合または購読を中止する場合は、http://lists.mysql.com/ にアクセスしてください。購読または購読中止に関するメッセージはいずれのメーリングリストにも送信しないでください。送信した場合、そのメッセージが多数の他のユーザに自動的に配信されてしまいます。
ローカルサイトに MySQL メーリングリストの購読者が多数いる場合、lists.mysql.com からサイトに送信されたメッセージがローカルリストに配信されるように、ローカルのメーリングリストが作成されている場合があります。このような場合、ローカルの MySQL リストへの追加またはリストからの削除については、システム管理者にお問い合わせください。
メールプログラム内の個別のメールボックスにメーリングリストが送信されるようにするには、メッセージヘッダに基づいてフィルタを設定してください。List-ID: または Delivered-To: ヘッダを使用して、リストのメッセージを識別することができます。
MySQL メーリングリストは以下のとおりです。
announce
mysql
mysql-digestmysql リストである。このリストを購読すると、全リストのメッセージを受け取ることになる。これは、1 日 1 回大きなメールメッセージとして送信される。
bugsMySQL の最新リリース以降に報告された問題を常に把握しておきたいユーザや、バグの検出と修正のプロセスに積極的に参加したいユーザにとって興味深いリストである。 「1.7.1.3 バグまたは問題を報告する方法」 節 参照 。
bugs-digestbugs リストである。
internals
internals-digestinternals リストである。
mysqldoc
mysqldoc-digestmysqldoc リストである。
benchmarks
benchmarks-digestbenchmarks リストである。
packagers
packagers-digestpackagers リストである。
java
java-digestjava リストである。
win32
win32-digestwin32 リストである。
myodbc
myodbc-digestmyodbc リストである。
mysqlccMySQL Control Center グラフィカルクライアントに関するすべてのトピックに使用される。
mysqlcc-digestmysqlcc リストである。
plusplus
plusplus-digestplusplus リストである。
msql-mysql-modulesDBD-mysql と呼ばれている msql-mysql-modules を使用した MySQL の Perl サポートに関するすべてのトピックに使用される。
msql-mysql-modules-digestmsql-mysql-modules リストである。
質問に対する回答が MySQL メーリングリストから得られなかった場合、MySQL AB から有料でサポートを受ける方法があります。その場合は、MySQL の開発者と直接連絡を取ることができます。 「1.4.1 MySQL AB によって提供されるサポート」 節 参照 。
以下は、英語以外の言語による MySQL メーリングリストです。これらのリストは MySQL AB が運営しているものではないので、品質は保証いたしません。
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 を電子メールでお送りください。
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
バグレポートまたは質問を投稿する前に、以下のことを行ってください。
マニュアルやアーカイブで回答を見つけることができなかった場合、ローカルの MySQL の専門家とともに調べてください。それでも質問に対する回答を見つけることができなかった場合は、当社に問い合わせる前に、次のセクションに記載されているガイドラインに従って MySQL メーリングリストにメールをお送りください。
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
当社のバグデータベースは公開されているので、すべてのユーザが http://bugs.mysql.com/ で参照および検索することができます。システムにログインすると、新しいレポートを入力することもできます。
適切なバグレポートを作成するには忍耐が必要ですが、最初に正しく作成しておくと、当社にとってもユーザ自身にとっても時間の節約になります。バグの詳細なテストケースを含む適切なバグレポートの場合、次のリリースでバグが修正される可能性が非常に高くなります。このセクションでは、当社にとってあまり、またはまったく役に立たない作業にユーザが時間を費やさなくて済むように、レポートを正しく作成する方法を説明します。
バグレポート（または問題に関するレポート）の生成には mysqlbug スクリプトを使用することをお勧めします。mysqlbug は、`scripts' ディレクトリ（ソースディストリビューション）および MySQL インストールディレクトリ下の `bin' ディレクトリ（バイナリディストリビューション）にあります。mysqlbug を使用することができない場合でも（Windows を使用している場合など）、このセクションに記されている必要な情報すべてをレポートに記載する必要があります（最も重要なのは、オペレーティングシステムの説明と MySQL バージョンです）。
mysqlbug スクリプトを使用すると、以下の情報のほとんどを自動的に確認することができるので、簡単にレポートを生成することができます。ただし、重要な情報が不足している場合は、その情報をメッセージに追加してください。このセクションをよく読んで、ここに記されているすべての情報をレポートに記載してください。
できれば、MySQL サーバの最新の製品版または開発版を使用して問題をテストしてから投稿してください。だれもが記載されているテストケースで mysql test < script を使用するだけでバグを再現したり、バグレポートに含まれているシェルまたは Perl スクリプトを実行したりすることができるようにする必要があります。
バグデータベース（http://bugs.mysql.com/ ）に投稿されたすべてのバグは、次の MySQL リリースで修正または文書化されます。小規模なコードの変更のみで問題を修正できる場合は、当社でも問題を修正するパッチを投稿します。
バグを報告する場所は通常、http://bugs.mysql.com/ です。
MySQL で重大なセキュリティバグを見つけた場合は、security@mysql.com に電子メールをお送りください。
再現可能なバグレポートがある場合、バグデータベース（http://bugs.mysql.com/ ）に報告してください。この場合も、まず mysqlbug スクリプトを実行して、システムに関する情報を確認することをお勧めします。再現可能なバグは、次の MySQL リリースで修正される可能性が高くなります。
他の問題を報告する場合は、MySQL メーリングリストのいずれかを使用してください。
情報が多すぎるメッセージに対応することはできますが、少なすぎるメッセージに対応することはできません。多くの場合、問題の原因がわかっていると思い、細部を重要でないと考えるため、事実を省略してしまいます。記載するかどうかを迷ったときは、記載することをお勧めします。最初に十分な情報を記載していなかったために再度質問して、回答を待たなければならなくなるよりも、レポートに数行を追加する方が、はるかに時間が節約される上に、煩わしくありません
バグレポートで最もよくある誤りは、(a) 使用している MySQL ディストリビューションのバージョン番号を記載していない、(b) MySQL サーバがインストールされているプラットフォームの説明（プラットフォームの種類およびバージョン番号を含む）が十分でないというものです。これは非常に重要な情報なので、ほとんどの場合、この情報が記載されていないバグレポートは役に立ちません。"この機能が使用できないのはなぜですか?" という質問を受けることがよくあります。その場合、要求した機能がその MySQL バージョンに実装されていなかったり、レポートに記載されているバグが新しい MySQL バージョンですでに修正されていたりすることがあります。エラーがプラットフォーム依存である場合もあります。そのような場合、オペレーティングシステムやプラットフォームのバージョン番号を知らないで問題を修正することはほとんど不可能です。
また、コンパイラが問題に関連している場合は、コンパイラに関する情報も記載してください。ユーザがコンパイラのバグを見つけると、MySQL 関連の問題であると考えることがよくあります。ほとんどのコンパイラは常に開発中なので、バージョンごとに改良されています。問題がコンパイラに関連するものであるかどうかを判断するには、使用しているコンパイラを知る必要があります。コンパイルに関するすべての問題はバグと見なし、適宜報告してください。
問題に関する適切な説明がバグレポートに記載されていると、最も効果的です。そのため、問題につながったすべての操作の適切な例を挙げ、問題自体を詳細に記述してください。最も効果的なレポートは、バグや問題を再現する方法を示す詳細な例が記載されたものです。 「E.1.6 テーブルが破損した場合にテストケースを作成する」 節 参照 。
プログラムでエラーメッセージが生成された場合、そのメッセージをレポートに記載することが非常に重要です。プログラムを使用するアーカイブから情報を検索しようとする場合、報告されたエラーメッセージがプログラムで生成されたものと正確に一致している方が効果的です（大文字小文字の違いにも注意してください）。エラーメッセージを覚えるのではなく、メッセージ全体をレポートにコピーして貼り付けてください。
MyODBC に関する問題がある場合、MyODBC トレースファイルを生成し、レポートともに送信してください。 「11.2.7 MyODBC に関する問題の報告」 節 参照 。
レポートを読むユーザの多くが 80 桁ディスプレイを使用します。したがって、mysql コマンドラインツールを使用してレポートまたはサンプルを生成する際には、そのようなディスプレイの有効な幅を超える出力については、--vertical オプション（または \G ステートメント終端記号）を使用する必要があります（たとえば、EXPLAIN SELECT ステートメントの場合。このセクションの後述のサンプルを参照）。
mysqladmin version を実行する。mysqladmin は、MySQL インストールディレクトリ下の `bin' ディレクトリにある。
uname -a を実行する。Windows を使用している場合、名前とバージョン番号を取得するには、通常 "マイ コンピュータ" アイコンをダブルクリックし、"ヘルプ/バージョン情報" メニューをプルダウンする。
mysqld が停止した場合、mysqld のクラッシュの原因となったクエリも報告する必要がある。通常、ログを有効にして mysqld を実行すると、これを検出することができる。 「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 からの出力をメールに記載して、システムの動作に関する情報を提供する必要がある。
mysqldump を使用してテーブルをダンプし、問題を説明する `README' ファイルを作成する必要がある。
tar と gzip または zip を使用してファイルの圧縮アーカイブを作成し、ftp を使用してそのアーカイブを ftp://support.mysql.com/pub/mysql/secret/ に転送する。その後、バグデータベース（http://bugs.mysql.com/ ）に問題を入力する。
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 サーバでサポートされていない可能性が非常に高い。現在のバージョンを使用している場合、使用している構文が http://www.mysql.com/doc/ のマニュアルで扱われていなければ、そのクエリは MySQL サーバでサポートされていない。その場合は、自分で構文を実装するか、licensing@mysql.com に電子メールを送信して、その構文を実装するように依頼するしかない。
使用している構文がマニュアルで扱われていても、古いバージョンの MySQL サーバを使用している場合は、MySQL の変更履歴で構文が実装された時期を確認する必要がある。この場合は、新しいバージョンの MySQL サーバにアップグレードする方法がある。 「D. MySQL Change History」 節 参照 。
myisamchk または CHECK TABLE と REPAIR TABLE を使用して、まずテーブルをチェックしてから、修復を試みる必要がある。 「4. データベース管理」 節 参照 。
mysqld が停止されない限り、mysqld によってテーブルが破壊されることはない。mysqld が停止した原因が特定されれば、当社はその問題の解決策をはるかに簡単に提供することができる。 「A.1 問題の原因を突き止める方法」 節 参照 。
サポート契約を結んでいるお客様は、他のユーザが同じ問題に遭遇しているかどうか（また、その問題が解決されているかどうか）を確認するために該当するメーリングリストにバグレポートを投稿するだけでなく、優先的に処理されるように mysql-support@mysql.com にも投稿してください。
MyODBC におけるバグの報告については、 「11.2.4 MyODBC に関する問題を報告する方法」 を参照してください。
一般的な問題に対する解決策については、 「A. 問題と一般的なエラー」 を参照してください。
メーリングリストではなく、個人宛てに回答が送信された場合、問題の解決に役立った回答が他のユーザにも役立つように、回答を要約してメーリングリストに送信するのがエチケットであると思います。
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
多数のユーザにとって興味深いと思われる回答については、質問した個人に直接返信するのではなく、メーリングリストに投稿することができます。その場合、元の投稿者以外のユーザにも役立つように、一般的な回答をするようにしてください。リストに投稿する際には、回答が前の回答と重複していないことを確認してください。
元のメッセージ全体を引用するのではなく、質問の重要な部分を回答に要約してください。
HTML モードがオンになっているブラウザからメールメッセージを投稿しないでください。多くのユーザはブラウザでメールを読みません。
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
さまざまな MySQL メーリングリストに加え、IRC（インターネットリレーチャット）にも経験豊富なコミュニティがあります。以下は、当社が現在把握している最もすぐれたネットワーク/チャネルです。
#mysql
MySQL に関する質問が中心であるが、他のデータベースや SQL に関する質問も受け付けている。
#mysqlphp
MySQL+PHP という一般的な組み合わせに関する質問。
#mysqlperl
もう 1 つの一般的な組み合わせ、MySQL+Perl に関する質問。
#mysql
MySQL に関する質問。
IRC ネットワークに接続する IRC クライアントソフトウェアを探している場合は、X-Chat（http://www.xchat.org/ ）を参照してください。X-Chat（GPL ライセンス）は、Unix および Windows プラットフォームで使用することができます。
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
このセクションでは、MySQL と ANSI/ISO SQL 標準との関連を説明します。MySQL サーバには SQL 標準に対する多数の拡張機能があります。ここでは、それらの拡張機能と使用方法を説明します。また、MySQL サーバに不足している機能と、差異を解決する方法に関する情報も提供します。
当社の目標は、正当な理由なく、あらゆる用途に対して MySQL サーバの使いやすさを制限しないことです。考えられるすべての用途に対応する開発を行うリソースがそろっていなくても、新しい領域で MySQL サーバを使用しようとしているユーザを常に喜んで援助し、アドバイスを提供します。
製品に関する当社の主な目標の 1 つは、速度や信頼性を犠牲にすることなく、SQL-99 標準への準拠に向けて開発を続けることです。大部分のユーザにとって MySQL サーバが大幅に使いやすくなるのであれば、当社は SQL に対する拡張機能や SQL 以外の機能のサポートを積極的に追加します（MySQL サーバ 4.0 の新しい HANDLER インタフェースは、この方針の一例です。 「6.4.9 HANDLER 構文」 節 参照 。)
当社は、負荷が高い Web/ログの使用とミッションクリティカルな年中無休の使用の両方に対応するために、トランザクションデータベースと非トランザクションデータベースのサポートを継続します。
MySQL サーバは、小規模なコンピュータシステムで中規模のデータベース（1,000 万 〜 1 億レコード、または 1 テーブルあたり約 100 MB）を使用することを目的として最初から設計されました。テラバイト規模のデータベースでも適切に動作するとともに、ハンドヘルドデバイスや組み込み用途により適した小規模な MySQL をコンパイルできるように、MySQL サーバの拡張を続けます。MySQL サーバのコンパクトな設計によって、ソースツリーで競合することなく、これらのどちらの方向も実現することができます。
現時点では、リアルタイムのサポートは考えていません（ただし、レプリケーションサービスを使用して、すでに多くのことを実行することができます）。
データベースクラスタのサポートは、新しいストレージエンジンの実装によって 2004 年内に開始される予定です。
データベースサーバでの XML サポートの提供を考えています。
| 1.8.1 MySQL が準拠する標準 | ||
| 1.8.2 ANSI モードでの MySQL の実行 | ||
| 1.8.3 SQL-92 標準に対する MySQL 拡張機能 | ||
| 1.8.4 MySQL と SQL-92 との違い | ||
| 1.8.5 MySQL における制約の処理 | ||
| 1.8.6 MySQL の既知のエラーと設計上の問題 |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
エントリレベルは SQL-92 です。ODBC レベルは 0 〜 3.51 です。
コードの速度と品質を犠牲にすることなく、SQL-99 標準を完全にサポートすることを目標としています。
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
--ansi または --sql-mode=ANSI オプションを指定して mysqld を開始すると、MySQL サーバの動作は次のように変わります。
|| は、OR のシノニムではなく、文字列連結演算子になる。
USER() 関数があるので、mysql データベース内の user テーブルの名前とそのテーブル内の User カラムの名前が予約語となるため、これらを引用符で囲まなければならない。
SELECT "User" FROM mysql."user"; |
REAL は、DOUBLE のシノニムではなく、FLOAT のシノニムとなる。
SERIALIZABLE となる。 「6.7.6 SET TRANSACTION 構文」 節 参照 。
GROUP BY でフィールド/式を使用することができる。
ANSI モードでサーバを実行するのは、以下のオプションを指定してサーバを起動するのと同じことです。
--sql-mode=REAL_AS_FLOAT,PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE,ONLY_FULL_GROUP_BY --transaction-isolation=SERIALIZABLE |
MySQL 4.1 では、次の 2 つのステートメントで同じ動作を実現することができます。
SET GLOBAL TRANSACTION ISOLATION LEVEL SERIALIZABLE; SET GLOBAL sql_mode = "REAL_AS_FLOAT,PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE,ONLY_FULL_GROUP_BY"; |
MySQL 4.1.1 では、sql_mode オプションを次のように使用することもできます。
SET GLOBAL sql_mode="ansi"; |
この場合、sql_mode 変数の値は、ANSI モードに関連するすべてのオプションに設定されます。結果を確認するには、以下を実行します。
mysql> SET GLOBAL sql_mode="ansi"; mysql> SELECT @@GLOBAL.sql_mode; +---------------------------------------------------------------------------+ | @global.sql_mode | +---------------------------------------------------------------------------+ | REAL_AS_FLOAT,PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE,ONLY_FULL_GROUP_BY | +---------------------------------------------------------------------------+ 1 row in set (0.00 sec) |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
MySQL サーバには、他の SQL データベースにはない拡張機能があります。それらの拡張機能を使用した場合、他の SQL サーバにコードを移植できなくなるので注意してください。場合によっては、MySQL 拡張機能を含むコードを記述しても、/*! ... */ 形式のコメントを使用することで移植することができます。その場合、MySQL サーバでは、他の MySQL ステートメントと同様にコメント内のコードが解析および実行されますが、他の SQL サーバでは拡張機能が無視されます。次に例を示します。
SELECT /*! STRAIGHT_JOIN */ col_name FROM table1,table2 WHERE ... |
'!' の後ろにバージョン番号を追加すると、MySQL バージョンが、使用されているバージョン番号以降の場合にのみ、構文が実行されます。
CREATE /*!32302 TEMPORARY */ TABLE t (a INT); |
つまり、バージョン 3.23.02 以降を使用している場合、MySQL サーバで TEMPORARY キーワードが使用されます。
以下は、MySQL 拡張機能の一覧です。
MEDIUMINT、SET、ENUM、およびさまざまな BLOB および TEXT 型。
AUTO_INCREMENT、BINARY、NULL、UNSIGNED、および ZEROFILL。
BINARY 属性を指定してカラムを宣言するか、BINARY キャストを使用して、MySQL サーバホストで使用される ASCII の順序に従って比較が行われるようにする必要がある。
これには、次のような意味がある。
db_name.tbl_name 構文を使用して、さまざまなデータベース内のテーブルにアクセスすることができる。同様の機能を備えた SQL サーバもあるが、これはユーザスペースと呼ばれる。MySQL サーバでは、CREATE TABLE ralph.my_table...IN my_tablespace のようなテーブルスペースはサポートされない。
LIKE を使用することができる。
SELECT ステートメントでの INTO OUTFILE および STRAIGHT_JOIN の使用。 「6.4.1 SELECT 構文」 節 参照 。
SELECT ステートメントでの SQL_SMALL_RESULT オプション。
EXPLAIN SELECT。
CREATE TABLE ステートメントでの INDEX または KEY の使用。 「6.5.3 CREATE TABLE 構文」 節 参照 。
CREATE TABLE での TEMPORARY または IF NOT EXISTS の使用。
list に複数の要素がある COUNT(DISTINCT list) の使用。
ALTER TABLE ステートメントでの CHANGE col_name、DROP col_name、DROP INDEX、IGNORE、または RENAME の使用。 「6.5.4 ALTER TABLE 構文」 節 参照 。
RENAME TABLE の使用。 「6.5.5 RENAME TABLE 構文」 節 参照 。
ALTER TABLE ステートメントでの複数の ADD、ALTER、DROP、または CHANGE 節の使用。
DROP TABLE でのキーワード IF EXISTS の使用。
DROP TABLE ステートメントで複数のテーブルを破棄することができる。
UPDATE および DELETE ステートメントの ORDER BY および LIMIT 節。
INSERT INTO ... SET col_name = ... 構文。
INSERT および REPLACE ステートメントの DELAYED 節。
INSERT、REPLACE、DELETE、および UPDATE ステートメントの LOW_PRIORITY 節。
LOAD DATA INFILE の使用。多くの場合、この構文は Oracle の LOAD DATA INFILE と互換性がある。 「6.4.8 LOAD DATA INFILE 構文」 節 参照 。
ANALYZE TABLE、CHECK TABLE、OPTIMIZE TABLE、および REPAIR TABLE ステートメント。
SHOW ステートメント。 「4.6.8 SHOW 構文」 節 参照 。
SET ステートメント。 「5.5.6 SET 構文」 節 参照 。
GROUP BY 部で、選択したすべてのカラムの名前を列挙する必要がない。これにより、ごく一部ではあるが、きわめて一般的なクエリのパフォーマンスが向上する。 「6.3.7 GROUP BY 節で使用する関数と修飾子」 節 参照 。
GROUP BY で ASC および DESC を指定することができる。
|| および && 演算子が論理 OR および AND を意味すると解釈される。MySQL サーバでは、|| と OR、および && と AND はシノニムである。このすぐれた構文のために、MySQL サーバでは、文字列の連結に標準 SQL-99 の || 演算子を使用することができない。代わりに、CONCAT() を使用する。CONCAT() には引数をいくつでも使用できるので、|| 演算子の使用を MySQL サーバに変換するのは簡単である。
CREATE DATABASE または DROP DATABASE。 「6.5.1 CREATE DATABASE 構文」 節 参照 。
% 演算子は MOD() のシノニムである。したがって、N % M は MOD(N,M) と同じである。% は、C プログラマを対象として、また PostgreSQL との互換性を確保するためにサポートされている。
=、<>、<=、<、>=、>、<<、>>、<=>、AND、OR、または LIKE 演算子を、SELECT ステートメントの FROM の左側のカラム比較で使用することができる。次に例を示す。
mysql> SELECT col1=1 AND col2=2 FROM tbl_name; |
LAST_INSERT_ID() 関数。 「11.1.3.32 mysql_insert_id()」 節 参照 。
REGEXP および NOT REGEXP 拡張正規表現演算子。
CONCAT() または CHAR()（MySQL サーバでは、これらの関数は引数をいくつでも使用することができる）。
BIT_COUNT()、CASE、ELT()、FROM_DAYS()、FORMAT()、IF()、PASSWORD()、ENCRYPT()、MD5()、ENCODE()、DECODE()、PERIOD_ADD()、PERIOD_DIFF()、TO_DAYS()、または WEEKDAY() 関数。
TRIM() の使用。SQL-99 では、1 つの文字しか削除できない。
GROUP BY 関数 STD()、BIT_OR()、BIT_AND()、BIT_XOR()、および GROUP_CONCAT()。 「6.3.7 GROUP BY 節で使用する関数と修飾子」 節 参照 。
DELETE + INSERT の代わりの REPLACE の使用。 「6.4.7 REPLACE 構文」 節 参照 。
FLUSH、RESET、および DO ステートメント。
:= を使用してステートメント内で変数を設定することができる。
SELECT @a:=SUM(total),@b=COUNT(*),@a/@b AS avg FROM test_table; SELECT @t1:=(@t2:=1)+@t3:=4,@t1,@t2,@t3; |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
MySQL サーバを ANSI SQL 標準（SQL-92/SQL-99）および ODBC SQL 標準に準拠したものにすることを目標としていますが、以下のように、MySQL サーバが異なる動作を示すことがあります。
VARCHAR 型のカラムでは、値が格納される際に後続のスペースが削除される。 「1.8.6 MySQL の既知のエラーと設計上の問題」 節 参照 。
CHAR 型のカラムが自動的に VARCHAR 型のカラムに変更されることがある。 「6.5.3.1 カラムの暗黙的な変更」 節 参照 。
REVOKE を発行する必要がある。 「4.4.1 GRANT および REVOKE の構文」 節 参照 。
| 1.8.4.1 サブクエリ | ||
1.8.4.2 SELECT INTO TABLE | ||
| 1.8.4.3 トランザクションとアトミックオペレーション | ||
| 1.8.4.4 ストアドプロシージャとトリガ | ||
| 1.8.4.5 外部キー | ||
| 1.8.4.6 ビュー | ||
| 1.8.4.7 コメントの開始記号としての `--' |
優先順位に従って並べられた、新しい拡張機能が MySQL サーバに追加される時期を示す一覧については、オンラインの MySQL TODO リスト（http://www.mysql.com/doc/en/TODO.html ）を参照してください。これは、このマニュアルの TODO リストの最新版です。 「1.6 MySQL の今後（TODO）」 節 参照 。
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
MySQL バージョン 4.1 では、サブクエリと派生テーブル（名前のないビュー）がサポートされています。 「6.4.2 サブクエリ構文」 節 参照 。
4.1 より前のバージョンの MySQL については、結合などの方法によって、ほとんどのサブクエリを記述し直すことができます。 「6.4.2.11 初期の MySQL バージョンに合わせたサブクエリの書き換え」 節 参照 。
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
SELECT INTO TABLE
MySQL サーバでは、Sybase SQL 拡張機能 SELECT ... INTO TABLE ... はまだサポートされていません。代わりに、SQL-99 構文 INSERT INTO ... SELECT ... がサポートされています。これらは、基本的には同じです。 「6.4.3.1 INSERT ... SELECT 構文」 節 参照 。
INSERT INTO tblTemp2 (fldID)
SELECT tblTemp1.fldOrder_ID
FROM tblTemp1 WHERE tblTemp1.fldOrder_ID > 100;
|
また、SELECT INTO OUTFILE... または CREATE TABLE ... SELECT を使用することもできます。
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
MySQL サーバ（バージョン 3.23-max およびすべてのバージョン 4.0 以降）では、InnoDB および BDB トランザクションストレージエンジンでトランザクションがサポートされています。InnoDB は、完全に ACID に準拠しています。 「7. MySQL のテーブル型」 節 参照 。
MySQL サーバのその他の非トランザクションテーブル型（MyISAM など）は、"アトミックオペレーション"と呼ばれる別のデータ整合性のパラダイムに従います。トランザクションの観点では、MyISAM テーブルは事実上、常に AUTOCOMMIT=1 モードで動作すると言えます。アトミックオペレーションでは多くの場合、パフォーマンスの高さに値する整合性が確保されます。
両方のパラダイムをサポートする MySQL サーバでは、ユーザはアトミックオペレーションの速度を必要とするか、アプリケーションでトランザクション機能を使用する必要があるかを選択することができます。この選択は、テーブルごとに行うことができます。
ほとんどの場合、トランザクションテーブル型と非トランザクションテーブル型のどちらを選ぶかの決め手となるのはパフォーマンスです。トランザクションテーブルの場合、はるかに大きなメモリとディスク領域が必要で、CPU のオーバーヘッドも大きくなります。しかし、InnoDB のようなトランザクションテーブル型には特有の機能も多数あります。MySQL サーバのモジュール設計によって、このようなさまざまなストレージエンジンすべてを同時に使用することができるので、さまざまな要件に合わせて、あらゆる条件で最適なパフォーマンスを確保することが可能です。
しかし、MySQL サーバの機能を使用して、非トランザクションの MyISAM テーブルでも厳密な整合性を確保するにはどのようにすればよいのでしょうか。また、非トランザクションテーブルの機能はトランザクションテーブル型にどのように対抗できるのでしょうか。
COMMIT ではなく ROLLBACK の呼び出しに依存するようにアプリケーションが作成されている場合、トランザクションの方が便利である。また、トランザクションでは、完了していない更新や失敗した活動がデータベースにコミットされることはない。サーバには自動ロールバックを行う機会が与えられ、データベースは保護される。
MySQL サーバでは、ほとんどの場合、更新前に簡単なチェックを組み込んだり、データベースの不整合をチェックして、不整合が発生した場合には自動的に修復または警告する簡単なスクリプトを実行したりすることで、発生する可能性がある問題を解決することができる。MySQL ログを使用したり、別のログを 1 つ追加したりするだけで、通常、データの整合性が失われることなく、完全にテーブルを修復することができる。
LOCK TABLES またはアトミックな更新を使用して解決することができる。これによって、サーバが自動的に停止するという、トランザクションデータベースシステムと共通する問題が回避される。
MySQL サーバを安全に使用するには、トランザクションテーブルを使用するかどうかに関係なく、バックアップを作成し、バイナリログをオンにすればよいだけである。これにより、他のトランザクションデータベースシステムで可能なように、どのような状況からもリカバリすることができる。使用するデータベースシステムに関係なく、どのような場合でもバックアップを作成することが望ましいのは当然である。
トランザクションパラダイムには長所と短所があります。多数のユーザおよびアプリケーション開発者は、停止が発生する、または停止が必要な問題に関するコード化の容易さに頼っています。しかし、アトミックオペレーションのパラダイムに慣れていなかったり、トランザクションの方が詳しいという場合でも、非トランザクションテーブルの速度が、最も高速で最適に調整されたトランザクションテーブルの速度の 3 倍から 5 倍も速いという長所を考えてみてください。
整合性が最も重要な状況では、MySQL サーバは、非トランザクションテーブルでもトランザクションレベルの信頼性と整合性を提供します。LOCK TABLES を使用してテーブルをロックすると、整合性チェックが行われるまで、すべての更新が延期されます。読み取りロック（書き込みロックの逆）のみが設定されている場合、読み取りと挿入は引き続き行うことができます。新しく挿入したレコードは、読み取りがロックされているクライアントには、読み取りロックが解除されるまで表示されません。INSERT DELAYED を使用すると、ロックが解除されるまで挿入をローカルキューに入れることができ、クライアントは挿入が完了するまで待機する必要はありません。 「6.4.3.2 INSERT DELAYED 構文」 節 参照 。
ここでいう "アトミック" とは、魔法のようなものではありません。個々の更新の実行中は、他のユーザがそれを妨害できないようにするとともに、自動ロールバック（あまり注意を払わなかった場合に、トランザクションテーブルで行われることがあります）が行われないようにすることができるというだけです。また、MySQL サーバでは、ダーティリードが行われることもありません。
非トランザクションテーブルを使用する際のテクニックは、以下のとおりです。
LOCK TABLES を使用して、通常はトランザクションを必要とするループをコード化することができる。そのため、実行中にレコードを更新するカーソルが不要である。
ROLLBACK を使用しないように、以下の方法を使用することができる。
LOCK TABLES ... を使用して、アクセスするすべてのテーブルをロックする。
UNLOCK TABLES を使用して、ロックを解除する。
これは通常、ロールバックが行われる可能性があるトランザクションを使用するよりも、はるかに速い方法である。ただし、更新の途中でスレッドが停止された場合は、この方法では対応することができない。その場合、すべてのロックが解除されるが、一部の更新が実行されていない可能性がある。
たとえば、顧客情報に対して更新を行う場合、変更された顧客データのみを更新し、変更されたデータ、または変更されたデータに依存するデータが元のレコードと比較して変更されていないことだけをテストする。変更されたデータのテストは、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() を使用することで、はるかに効率的に処理することができる。 「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; |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
ストアドプロシージャは、バージョン 5.0 開発ツリーで実装されます。 「2.3.4 開発ソースツリーからのインストール」 節 参照 。
この試みは SQL-99 に基づくもので、Oracle PL/SQL に類似した（ただし、同じではありません）基本構文を使用します。これに加え、外部言語でフックする SQL-99 フレームワークも実装します。
ストアドプロシージャは、サーバでコンパイルし、格納することができる SQL コマンドのセットです。これが行われると、クライアントはクエリ全体の再発行を繰り返す必要がなく、ストアドプロシージャを参照することができます。その結果、クエリを一度解析するだけで済み、サーバとクライアント間で送信される情報が少なくなるので、全体的なパフォーマンスが向上します。また、サーバに関数のライブラリを作成することで、概念レベルを高めることもできます。ただし、サーバ側で行われる作業が増え、クライアント（アプリケーション）側で行われる作業が少なくなるので、ストアドプロシージャによってデータベースサーバシステムの負荷が高くなります。
トリガは、MySQL バージョン 5.1 で実装される予定です。トリガは、実質的にはストアドプロシージャの一種で、特定のイベントが発生すると呼び出されます。たとえば、トランザクションテーブルからレコードが削除されるたびにトリガされるストアドプロシージャや、すべてのトランザクションが削除されると、顧客テーブルから対応する顧客を自動的に削除するストアドプロシージャを設定することができます。
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
MySQL サーバ 3.23.44 以降では、CASCADE、ON DELETE、および ON UPDATE を含む外部キー制約のチェックが InnoDB テーブルでサポートされています。 「7.5.5.2 FOREIGN KEY 制約」 節 参照 。
他のテーブル型については、MySQL サーバでは現在、CREATE TABLE コマンドで FOREIGN KEY 構文のみが解析されますが、この情報は使用/保存されません。近いうちに、この情報がテーブル仕様ファイルに保存され、mysqldump および ODBC によって取得できるように、この実装を拡張する予定です。さらにその後には、MyISAM テーブルについても外部キー制約を実装する予定です。
SQL の外部キーはテーブルの結合に使用されるのではなく、参照整合性（外部キー制約）のチェックと確保に使用されます。SELECT ステートメントを使用して複数のテーブルから結果を得るには、次のようにテーブルを結合します。
SELECT * FROM table1,table2 WHERE table1.id = table2.id; |
「6.4.1.1 JOIN 構文」 節 参照 。 「3.6.6 外部キーの使用」 節 参照 。
制約として使用する際、アプリケーションによって MyISAM テーブルに適切な順序でレコードが挿入される場合は、外部キーを使用する必要はありません。
MyISAM テーブルについては、ON DELETE が実装されていないという問題に対処するには、外部キーがあるテーブルからレコードを削除する際に適切な DELETE ステートメントをアプリケーションに追加します。実際、この方法は外部キーを使用する場合と同じくらい簡単で（場合によっては、この方が簡単です）、移植性はそれよりもはるかに高くなります。
MySQL サーバ 4.0 では、複数テーブルの削除を使用して、1 つのコマンドで多数のテーブルからレコードを削除することができます。 「6.4.5 DELETE 構文」 節 参照 。
ON DELETE ... を含まない FOREIGN KEY 構文は多くの場合、自動 WHERE 節を生成する ODBC アプリケーションによって使用されます。
外部キーを誤って使用すると、深刻な問題が発生することがあるので注意してください。適切に使用した場合でも、外部キーのサポートは、参照整合性の問題を解決する上で役に立つことはあっても、重要な解決策にはなりません。
外部キーを使用するメリットは、以下のとおりです。
外部キーを使用するデメリットは、以下のとおりです。
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
ビューは現在実装中で、MySQL サーババージョン 5.0 または 5.1 で実装されます。
これまで、MySQL サーバは、アプリケーション作成者がデータベースの使用を完全に制御することができるアプリケーションや Web システムで最も多く使用されてきました。しかし、時間の経過とともに用途は変わってきており、ビューを重要視するユーザが増えています。
名前のないビュー（派生テーブル、SELECT の FROM 節内のサブクエリ）は、バージョン 4.1 ですでに実装されています。
ビューは、1 つのテーブルのように一連の関係（テーブル）にユーザがアクセスできるようにし、ユーザのアクセスをそれのみに制限する場合に便利です。また、ビューを使用して、レコード（特定のテーブルのサブセット）へのアクセスを制限することもできます。MySQL サーバには高度な特権システムがあるので、カラムへのアクセスを制限する場合にはビューを使用する必要はありません。 「4.3 一般的なセキュリティ関連事項と MySQL アクセス制御システム」 節 参照 。
多数の DBMS では、ビューに対する更新を行うことはできません。代わりに、個々のテーブルに対して更新を実行する必要があります。当社はビューの実装を設計する際に、理論的に更新可能なすべてのビューは実際にも更新可能でなければならないという、リレーショナルデータベースシステムに関する "コッドのルール #6" に SQL の範囲内で可能な限り準拠することを目標としています。
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
一部の他の SQL データベースでは、コメントを開始するために `--' が使用されます。MySQL サーバでは、コメント開始文字として `#' が使用されます。また、C コメントスタイルの /* this is a comment */ を使用することもできます。 「6.1.6 コメント構文」 節 参照 。
MySQL サーババージョン 3.23.3 以降では、`--' コメントスタイルを使用することができます。ただし、コメントの後にスペース（または、改行などの制御文字）が続く場合に限ります。これは、このコメントスタイルによって、!payment! の値を自動的に挿入する次のようなコードを使用した自動生成の SQL クエリで多数の問題が発生していたためです。
UPDATE tbl_name SET credit=credit-!payment! |
payment の値が負数の場合、どうなるかを考えてみてください。SQL では 1--1 が有効なので、コメントを `--' で開始できるようにした場合の影響は重大です。
MySQL サーババージョン 3.23.3 以降でコメントのこの方法の実装を使用した場合、1-- This is a comment は実際に安全です。
もう 1 つの安全な機能は、mysql コマンドラインクライアントによって `--' で始まるすべての行が削除されるというものです。
以下の情報は、3.23.3 より前のバージョンの MySQL を実行している場合にのみ関連します。
テキストファイルの SQL プログラムに `--' コメントが含まれている場合、次のコマンドを使用する必要があります。
shell> replace " --" " #" < text-file-with-funny-comments.sql \
| mysql database
|
通常の次のコマンドの代わりに、上記のコマンドを使用してください。
shell> mysql database < text-file-with-funny-comments.sql |
また、コマンドファイルを "その場で" 編集して、`--' コメントを `#' コメントに変更することもできます。
shell> replace " --" " #" -- text-file-with-funny-comments.sql |
次のコマンドで元に戻してください。
shell> replace " #" " --" -- text-file-with-funny-comments.sql |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
MySQL ではトランザクションテーブルとロールバックが有効でない非トランザクションテーブルの両方を使用することができるので、MySQL と他のデータベースとでは制約の処理が多少異なります。
エラー時にロールバックすることができない非トランザクションテーブルで多数のレコードを更新した場合の処理を実装しなければなりません。
基本的な概念は、検出可能なエラーをコンパイル時に生成し、受け取ったエラーから実行時にリカバリするというものです。ほとんどの場合にこれが実装されていますが、まだすべてについて実装されているわけではありません。 「1.6.4 近い将来に計画されている新機能」 節 参照 。
MySQL における基本的なオプションは、途中でステートメントを中止するか、問題からリカバリするためにできる限りのことを行って、処理を続行するかです。
さまざまな種類の制約に関する問題を以下で説明します。
| 1.8.5.1 PRIMARY KEY/UNIQUE KEY 制約 | ||
1.8.5.2 NOT NULL および DEFAULT 値制約 | ||
1.8.5.3 ENUM および SET 制約 |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
通常、主キー、ユニークキー、または外部キー違反を引き起こすレコードの挿入/更新を行おうとすると、エラーが発生します。InnoDB のようなトランザクションストレージエンジンを使用している場合、MySQL ではトランザクションが自動的にロールバックされます。非トランザクションストレージエンジンを使用している場合、MySQL はエラーが発生したレコードで停止し、残りのレコードは未処理のままになります。
この問題を解決するために、MySQL では、キー違反が発生する可能性があるほとんどのコマンドに IGNORE ディレクティブのサポートを追加しました（INSERT IGNORE ... など）。この場合、キー違反は無視され、引き続き次のレコードが処理されます。MySQL における処理に関する情報を取得するには、mysql_info() API 関数を使用します。MySQL バージョン 4.1 では SHOW WARNINGS コマンドを使用します。 「11.1.3.30 mysql_info()」 節 参照 。 「4.6.8.9 SHOW WARNINGS | ERRORS」 節 参照 。
現時点では、外部キーがサポートされているのは InnoDB テーブルのみです。 「7.5.5.2 FOREIGN KEY 制約」 節 参照 。MyISAM テーブルでの外部キーサポートは、MySQL 5.0 ソースツリーで実装される予定です。
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
NOT NULL および DEFAULT 値制約 非トランザクションテーブルを簡単に処理できるように、MySQL のすべてのフィールドにはデフォルト値が設定されています。
NOT NULL カラムにおける NULL や数値カラムにおける大きすぎる数値のように '正しくない' 値をカラムに挿入した場合、MySQL ではエラーを生成するのではなく、カラムを '最適可能値' に設定します。数値については、0、使用可能な最小値、または使用可能な最大値です。文字列については、空白文字列、またはカラム内で使用可能な最長文字列です。
つまり、NULL 値を使用することができないカラムに NULL を格納しようとすると、0 または "（空白文字列）が代わりに格納されます。単一レコードの挿入については、この後者の動作を -DDONT_USE_DEFAULT_FIELDS コンパイルオプションを使用して変更することができます。 「2.3.3 一般的な configure オプション」 節 参照 。この場合、非 NULL 値を必要とするすべてのカラムについて明示的に値を指定しない限り、INSERT ステートメントでエラーが生成されます。
前述のルールの理由は、クエリの実行が開始される前にこれらの条件をチェックできないためです。複数のレコードを更新した後で問題が発生した場合、テーブル型でサポートされていない可能性があるため、単にロールバックすることはできません。停止するというオプションは、この場合、更新が '未完了' のため、最悪のシナリオになる可能性があるので、適切ではありません。'できる限りのことを行って'、何も問題が発生していないものとして処理を続行する方が適切です。MySQL 5.0 では、自動フィールド変換に関する警告と、トランザクションテーブルのみを使用するステートメントで許可されていないフィールド割り当てが行われた場合にステートメントをロールバックすることができるオプションを提供することで、これを改善する予定です。
このことは、通常、フィールドの内容をチェックするために MySQL を使用するのではなく、アプリケーションでこれを処理しなければならないことを意味します。
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
ENUM および SET 制約
MySQL 4.x では、ENUM は実際の制約ではなく、特定の値セットのみを使用することができるフィールドを格納するためのより効率的な方法です。これは、NOT NULL が受け付けられないのと同じ理由によります。 「1.8.5.2 NOT NULL および DEFAULT 値制約」 節 参照 。
ENUM フィールドに正しくない値を挿入した場合、予約された列挙数 0 に設定され、文字列コンテキストでは空白文字列として表示されます。 「6.2.3.3 ENUM 型」 節 参照 。
SET フィールドに正しくない値を挿入した場合、その値は無視されます。 「6.2.3.4 SET 型」 節 参照 。
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
| 1.8.6.1 その後の MySQL バージョンで修正された 3.23 のエラー | ||
| 1.8.6.2 MySQL の未解決のバグと設計上の問題 |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
以下の既知のエラー/バグは、MySQL 3.23 では修正されていません。これらの修正には、より深刻な他のバグを引き起こす可能性がある多数のコード変更が関連するためです。また、これらのバグは '非致命的' または '許容範囲' として分類されています。
LOCK TABLE を実行した後、別のスレッドがテーブルをロックしようとしている間に同じ接続でそれらのテーブルのいずれかに対して DROP TABLE を実行した場合、デッドロックが発生することがある。ただし、関連するスレッドのすべてに KILL を実行することで、この問題を解決することができる。4.0.12 で修正済み。
SELECT MAX(key_column) FROM t1,t2,t3... が NULL を返す代わりに、カラムの最大値を返す。4.0.11 で修正済み。
WHERE を含まない DELETE FROM heap_table が動作しない。
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |
以下の既知の問題は、優先して修正されます。
FLUSH TABLES WITH READ LOCK によって CREATE TABLE または COMMIT がブロックされず、テーブルおよびバイナリログの完全バックアップを実行すると、バイナリログの位置に関する問題が発生する。
ANALYZE TABLE によって、mysqld を再実行するまでテーブルが使用できなくなることがある。この問題が発生した場合は、MySQL エラーファイルに次のようなエラーが生成される。
001207 22:07:56 bdb: log_flush: LSN past current end-of-log |
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 ... を実行しても、処理が進行中の未完了のトランザクションがテーブルにないとは限らない。
-A オプションを使用していない場合や rehash を使用している場合、データベース上で mysql クライアントを使用するのに時間がかかる。これは、大きなテーブルキャッシュがある場合に特に顕著である。
AUTO_INCREMENT カラムにゼロまたは NULL 値を挿入する CREATE ... SELECT または INSERT ... SELECT ステートメント。
ON DELETE CASCADE プロパティが設定された外部キーがあるテーブルからレコードを削除する場合の DELETE。
REPLACE ... SELECT、INSERT IGNORE ... SELECT。
ORDER BY 節がない場合のみである。
実際、たとえば、ORDER BY がない INSERT ... SELECT の場合、SELECT は、マスタおよびスレーブでオプティマイザによって行われる選択によっては、異なる順序でレコードを返すことがある（その結果、レコードに異なるランクが設定され、auto_increment カラムで異なる数を取得することになる）。マスタとスレーブでクエリが異なって最適化されるのは、以下の場合のみである。
OPTIMIZE TABLE がマスタテーブルでは実行されたが、スレーブテーブルでは実行されなかった場合などである（これを修正するために、MySQL 4.1.1 以降では、OPTIMIZE、ANALYZE、および REPAIR がバイナリログに書き込まれる）。
key_buffer_size など）が、マスタとスレーブで異なる。
また、この問題は、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 シリーズのいずれかのリリースで修正される予定である。
CHAR(255)）を使用することができない。これは、新しいテーブル定義ファイル形式が導入されるバージョン 5.1 で修正される予定である。
SET CHARACTER SET を使用した場合、データベース名、テーブル名、およびカラム名で変換された文字を使用することができない。
LIKE ... ESCAPE で ESCAPE とともに _ または % を使用することができない。
DECIMAL 型のカラムにさまざまな形式（+01.00、1.00、01.00）で数字が格納されている場合、GROUP BY によって各値が異なる値として見なされることがある。
WHERE なしで DELETE FROM merge_table を使用すると、テーブルに対するマッピングのみが消去され、マップされたテーブルの内容は一切削除されない。
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 型のカラムが同様に処理される点である。
ENUM 型および SET 型のカラムを 255 個までしか作成することができない。
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 によって更新される。
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 サーバと他の SQL サーバでは動作が多少異なる。これは単に、MySQL サーバでは SQL コマンドに対してロールバックが実行されないようにするためである。これは、アプリケーションでカラム値をチェックする必要があるときには多少不便な場合があるが、他の方法では非常に困難な最適化を MySQL サーバで実行することができるので、実質的には速度が大幅に向上する。
カラムを正しくない値に設定した場合、ロールバックが行われる代わりに、カラムに取りうる値のうち最適な値が格納される。
NULL 値を使用することができないカラムに NULL を格納しようとした場合、0 または "（空白文字列）が代わりに格納される（ただし、この動作は、-DDONT_USE_DEFAULT_FIELDS コンパイルオプションを使用して変更することができる）。
DATE 型および DATETIME 型のカラムに正しくない日付値（2000-02-31 や 2000-02-00 など）を格納することができる。その考えは、日付を検証するのは SQL サーバの役目ではないというものである。MySQL で日付を格納し、同じ日付を正確に取得できる場合、その日付は格納される。日付がまったく正しくない（サーバで日付を格納することができない）場合は、特殊な日付値 0000-00-00 がカラムに格納される。
ENUM 型のカラムをサポートされていない値に設定した場合、エラー値である空白文字列に設定される。数値の場合は、0 に設定される。
SET 型のカラムをサポートされていない値に設定した場合、その値は無視される。
PROCEDURE を実行した場合、PROCEDURE によってカラムが変換されないことがある。
MERGE 型のテーブルを作成する際に、基になるテーブルの型に互換性があるかどうかがチェックされない。
NaN、-Inf、および Inf 値を倍精度で処理することができない。これらを使用した場合、データをエクスポートおよびインポートしようとすると問題が発生する。中間的な解決策として、NaN を NULL（可能な場合）、-Inf および Inf をそれぞれ使用可能な最小および最大倍精度値に変更する必要がある。
ALTER TABLE を使用して MERGE テーブルで使用されているテーブルに UNIQUE インデックスを追加した後、ALTER TABLE を使用して MERGE テーブルに通常のインデックスを追加すると、一意でない古いキーがテーブルに存在していた場合、テーブルでキーの順序が変わる。これは、重複キーをできるだけ早く検出できるように、ALTER TABLE が UNIQUE キーを通常のキーの前に配置するためである。
以下は、MySQL の初期のバージョンにおける既知のバグです。
LOCK TABLES を使用してロックされている多数のテーブルのうちの 1 つのテーブルで DROP TABLE を実行した場合、ハングスレッドを取得することがある。
WRITE を含む LOCK table。
FLUSH TABLES。
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 節内の式にインデックスが使用されないためである。
プラットフォーム固有のバグについては、コンパイルおよび移植に関するセクションを参照してください。 「2.3 MySQL ソースディストリビューションのインストール」 節 参照 。 「E. 他システムへの移植」 節 参照 。
| [ << ] | [ >> ] | [Top ] | [Contents ] | [Index] | [ ? ] |