目次
MySQL R ソフトウェアによって、非常に高速で堅牢なマルチスレッド形式のマルチユーザ SQL(Structured Query Language)データベース サーバが実現します。MySQL サーバは、ミッション クリティカルで負荷が高い運用システムにも、大規模に展開されるソフトウェアへの組み込みにも対応するように設計されています。MySQL は MySQL AB の商標です。
MySQL ソフトウェアはデュアル ライセンス製品です。ユーザは、GNU 一般公衆利用許諾契約書(http://www.fsf.org/licenses/) の条件に基づいてオープン ソース/フリー ソフトウェア製品として MySQL ソフトウェアを使用することも、MySQL AB から標準の商用ライセンスを購入することもできます。さらに詳しいライセンス ポリシーや情報については http://www.mysql.com/company/legal/licensing/ を参照してください。
このマニュアルで特に興味深いセクションは以下のとおりです。
MySQL データベース サーバの機能に関する説明については、項1.4.3. 「MySQL の主な機能」 を参照してください。
今後のプランに関しては、次を参照してください 項1.5. 「MySQL の開発ロードマップ」。
インストールの手順については、次を参照してください 章?2. MySQL のインストールと更新。アップグレードに関する情報については、項2.11. 「MySQL のアップグレード」 を参照してください。
MySQL データベース サーバのチュートリアルについては、Tutorial を参照してください。
MySQL サーバの管理とコンフィギュレーションに関する情報は、章?4. データベース管理 を参照してください。
レプリケーション サーバを設定する情報については、章?5. レプリケーション を参照してください。
MySQL データベース サーバとその機能についてよくある質問に対する答えは、付録?A. Frequently Asked Questions About MySQL 5.1 を参照してください。
既知のバグや機能上の問題の一覧については、項B.1.8. 「Known Issues in MySQL」 を参照してください。
このプロジェクトへの全貢献者の一覧については、付録?E. Credits を参照してください。
新機能とバグ修正の履歴については、付録?C. MySQL Change History を参照してください。
新しいアーキテクチャまたはオペレーティング システムへの MySQL Database Software の移植に関するヒントについては、Porting to Other Systems を参照してください。
SQL
のサンプルとベンチマーク情報については、ベンチマーク
ディレクトリ(ディストリ ビューションの
sql-bench
)を参照。
重要:
エラー(多くの場合、「bugs」 と呼ばれます)の報告は、項1.7. 「質問またはバグの報告」 で記されている手順に従ってください。
MySQL
サーバで重大なセキュリティバグを見つけた場合は、<security@mysql.com>
に電子メールをお送りください。
これは、MySQL データベース
システムのリファレンス マニュアルです。
バージョン 5.1、リリース
5.1.15-betaの MySQL
ソフトウェアについて記述しています。機能など多くの違いがバージョン
5.1 と前のバージョンにあるため、
古いバージョンの MySQL
ソフトウェアの説明については意図していません。もしあなたが前リリースの
MySQL ソフトウェアを使用している場合には、
これは MySQL 5.0 について説明した
MySQL 5.0 Reference Manualを参照して下さい。
または、MySQL
3.23、4.0、そして4.1をカバーするMySQL
3.23, 4.0, 4.1 リファレンス
マニュアル
を参照して下さい。MySQL 5.1 のマイナー
バージョンとの変更点は、
リリース番号(5.1.x
)への参照とともに、
このテキストに書かれています。
これはリファレンス マニュアルなので、SQL やリレーショナル データベースの概念に関する一般的な説明は記載していません。また、ユーザの OS やコマンド ライン インタープレターの説明も記載していません。
MySQL データベース ソフトウェアは継続して開発が行われているので、リファレンス マニュアルも頻繁に更新されます。このマニュアルの最新版は、http://dev.mysql.com/doc/ から入手することができます。HTML、PDF、Windows CHM 版などのさまざまな形式で入手することも可能です。
リファレンス マニュアルのソース ファイルは、DocBook XML フォーマット内に書かれています。HTML バージョンとその他のフォーマットは、主に DocBook XSL スタイル シートを使用して自動的に作成されます。DocBook についてさらに詳しい情報は、http://docbook.org/ を参照してください。
このマニュアルの DocBook XML ソースは、http://dev.mysql.com/tech-resources/sources.html から利用することが可能です。.次のコマンドを実行して、文書の保管場所のコピーを確認できます。
svn checkout http://svn.mysql.com/svnpublic/mysqldoc/
MySQL を利用するにあたって質問がある場合は、メーリング リストやフォーラムを使用してお尋ねください。項1.6.1. 「MySQL メーリング リスト」 と 項1.6.2. 「MySQL フォーラムにおける MySQL コミュニティサポート」 を参照してください。このマニュアルへの追加や修正に関する提案は、マニュアル チーム(Documentation Team)にお送りください。
このマニュアルは当初、David Axmark と Michael 「Monty」 Widenius によって執筆されました。現在は、Paul DuBois、Stefan Hinz、Jon Stephens、Martin MC Brown および Peter Lavin で構成される MySQL マニュアル チームによって管理されています。その他多数の貢献者については 付録?E. Credits を参照してください。
このマニュアルの著作権はスウェーデンの会社 MySQL AB が所有しています。MySQL R と MySQL のロゴは、MySQL AB のトレードマークとして登録されています。本マニュアル内で用いられている上記以外のトレードマークおよび登録トレードマークにはそれぞれ所有者が存在し、識別目的でのみ使用されます。
このマニュアルは、以下の表記規則に従って記載されています。
このスタイルのフォント
は、SQL
ステートメント、データベース名、テーブル名、カラム名、C
コード、Perl
コード、および環境変数に使用されます。例:「供与テーブルをリロードするにはFLUSH
PRIVILEGES
を使用してください。」
このスタイルのフォント
は例であなたが入力する文字を示します。
このスタイルのフォントは実行プログラムとスクリプトの名前、たとえば、mysql (MySQLコマンド ラインのクライアントプログラム)やmysqld (MySQL サーバ実行プログラム)を示します。
このスタイルのフォント
はあなたが値を設定すべき変数の入力に使用されます。
ファイル名と階層名は、このように書かれます:「グローバルなmy.cnf
ファイルは階層/etc
に置かれます。」
文字シーケンスはこのように書かれます:「ワイルドカードを指定するには‘%
’文字を使用します。」
このスタイルのフォントは強調に使用されます。
このスタイルのフォントは表の見出しや特に強い強調を表す場合に使用されます。
特定のプログラムからコマンドを実行する必要があることを示す場合、コマンドの前にプログラムとプロンプトを記述します。たとえば、shell>
はログインシェルから実行するコマンドを示し、mysql>
は mysql クライアント
プログラムから実行するコマンドを示します。
shell>シェルコマンドをここに入力します
mysql>mysqlステートメントをここに入力します
「シェル」とはコマンド インタープリタのことです。Unixでは通常、sh、csh、bashなどのプログラムです。Windows では、Windows コンソールで通常実行される command.com や cmd.exe です。
コマンドやステートメントを例で入力したときには、プロンプトまでを入力しないでください。
データベース名、テーブル名、およびカラム名は多くの場合、コマンドに代入する必要があります。このような代入が必要であることを示す場合、このマニュアルでは
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
]
省略記号(...
)
はステートメントのセクションの省略、とりわけ複雑な構文の簡略化を示します。たとえば、INSERT
...SELECT
は INSERT
ステートメントの後にSELECT
ステートメントが続く場合を簡略して表記します。
省略記号はステートメントの反復も示します。たとえば次の例では、最初のコンマの後に続き複数の
reset_option
値を与えられています。
RESETreset_option
[,reset_option
] ...
シェル変数をセットするコマンドは Bourne
シェルの構文として示されます。たとえば、CC
環境変数をセットして configure
コマンドを実行するシーケンスは、Bourne
シェルの構文では次のようになります。
shell> CC=gcc ./configure
csh または tcshをご使用の際には、適宜変更して使用してください。
shell>setenv CC gcc
shell>./configure
MySQL ABはMySQLの創始者と主な開発者からなる会社です。最初はDavid Axmark, Allan Larsson, and Michael 「Monty」 Wideniusによってスウェーデンに創設されました。
当社は、MySQLソフトウェアの開発と新しいユーザへの当社のデータベースの普及に専念しております。MySQL AB は、MySQL のソースコード、MySQL のロゴと商標、およびこのマニュアルの著作権を所有しています。項1.4. 「MySQL データベース管理システムの概要」 を参照してください。
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 などがあります。これらの子会社はそれぞれ、アメリカとドイツにあります。
MySQL は最もよく知られているオープンソース SQL データベース管理システムで、MySQL AB によって開発、提供、サポートが行われています。MySQL AB は MySQL の開発者によって創設された営利会社で、MySQL データベース管理システムに関連するサービスを提供することでビジネスを構築しています。
MySQL の Web サイト(http://www.mysql.com/)には、MySQL ソフトウェアと MySQL AB に関する最新情報が掲載されています。
MySQL はデータベース管理システムです。
データベースとは、構造化されたデータの集合です。データベースには、簡単なショッピングリストから絵画のギャラリー、または社内ネットワークの膨大な量の情報など、さまざまなものがあります。コンピュータデータベースに格納されているデータに対して追加、アクセス、および処理などを行うには、MySQL サーバのようなデータベース管理システムが必要となります。コンピュータは大量のデータの処理に非常に優れているので、データベース管理システムは、スタンドアロンのユーティリティまたは他のアプリケーションの一部として、データ処理の中心的な役割を果たします。
MySQL はリレーショナルデータベース管理システムです。
リレーショナルデータベースでは、1つの大きな保管領域にすべてのデータが格納されるのではなく、個別のテーブルにデータが格納されます。これにより、速度と柔軟性が向上します。「MySQL」 の SQL は「Structured Query Language」 を表します。SQL はデータベースへのアクセスに使用される最も一般的な標準化言語で、ANSI/ISO SQL 標準によって定義されています。SQL 標準は 1986 年以降開発が繰り返され、複数のバージョンがあります。本マニュアルでは、「SQL-92」 は 1992年にリリースされた標準に、「SQL:1999」 は 1999年にリリースされた標準に、そして 「SQL:2003」 は標準の現バージョンに対応しています。「the SQL standard」 という用語は、任意の時点における現行バージョンの SQL 標準を表す場合に使用します。
MySQL ソフトウェアはオープンソースです。
オープン ソースとは、だれもがそのソフトウェアを使用し、変更できることを意味します。MySQL ソフトウェアは、だれもが無料でインターネットからダウンロードし、使用することができます。必要に応じて、ソース コードを調べ、ニーズに合わせて変更することができます。MySQL ソフトウェアでは、GPL(GNU 一般公衆利用許諾契約書http://www.fsf.org/licenses/)に基づいて、さまざまな状況でのソフトウェアの使用において許可されている事項と禁止されている事項が規定されています。GPL では不都合な場合や商用アプリケーションに MySQL コードを組み込む必要がある場合は、商用ライセンス版を購入することができます。詳しくは MySQL ライセンスを参照してください。(http://www.mysql.com/company/legal/licensing/).
MySQL データベース サーバ は、非常に高速で信頼性があり、簡単に使用することができます。
それを求めていたのでしたら、ぜひ試してください。また、MySQL サーバには、ユーザと密接に協力して開発された実用的な機能が備わっています。ベンチマークページで、他のデータベース管理システムと MySQL サーバのパフォーマンスを比較することができます。項6.1.4. 「MySQL ベンチマークスィート」 を参照してください。
MySQL サーバは当初、既存のソリューションよりもはるかに速く大規模なデータベースを処理することを目的として開発され、多くを要求される運用環境で数年間にわたって使用されています。引き続き開発が行われていますが、MySQL サーバは現在、便利で多彩な機能を備えています。その接続性、速度、安全性によって、MySQL サーバはインターネット上のデータベースへのアクセスに非常に適しています。
MySQL サーバはクライアント/サーバもしくは組み込まれたシステム。
MySQL データベースソフトウェア は、さまざまなバックエンドをサポートするマルチスレッド形式の SQL サーバ、複数の異なるクライアントプログラムおよびライブラリ、管理ツール、幅広いアプリケーションプログラミングインタフェース(API)から成るクライアント/サーバシステムです。
また、MySQL サーバはアプリケーションへのリンクが可能なマルチスレッド ライブラリとして提供されており、さらに小規模で高速な、管理しやすい製品を作り出すことができます。
MySQL をサポートする多数のソフトウェアが提供されています。
必要なアプリケーションや言語ですでに MySQL データベース サーバがサポートされていると思われます。
「MySQL」 の正式な発音は 「My Ess Que Ell」 ですが(「my sequel」 ではありません)、「my sequel」 と発音したり、ローカライズされた他の方法で発音してもかまいません。
当初は、高速で低レベルな独自の(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 の出生国であるウガンダに近い、タンザニアのアルーシャにある町の名前でもあります。
このセクションでは MySQL データベース ソフトウェアの重要な特徴の一部を説明します。現行版と最新情報を 項1.5. 「MySQL の開発ロードマップ」 で参照してください。おおむね、MySQL 全てのバージョンに対応しています。シリーズごとに新しく紹介される MySQL の機能については、対応するマニュアルの 「一言」 セクションを参照してください。
MySQL 4.0 と 4.1: MySQL 4.0 in a Nutshell, and MySQL 4.1 in a Nutshell.
MySQL 5.0: MySQL 5.0 in a Nutshell.
MySQL 5.1: MySQL 5.1 in a Nutshell.
内部および移植性:
C および C++ で記述されています。
さまざまなコンパイラでテストされています。
さまざまなプラットフォームで動作します。 項2.1.1. 「MySQL Community Server がサポートしているオペレーティング システム」 を参照してください。
GNU 移植性のために GNU Automake、Autoconf、および Libtool を使用しています。
MySQL サーバは多層で、独立モジュールでデザインされています。
カーネルスレッドを使用した完全なマルチスレッド。そのため、使用可能な場合、複数の CPU を簡単に使用することができます。
トランザクションストレージエンジンと非トランザクションストレージエンジンを備えています。
インデックス圧縮を備えた非常に高速な B-tree
ディスクテーブル(MyISAM
)
を使用しています。
別のストレージエンジンの追加が比較的容易です。これは、社内データベースへの SQL インタフェースを追加する場合に便利です。
スレッドベースの非常に高速なメモリ割り当てシステム。
最適化された one-sweep multi-join を使用した非常に迅速な結合。
テンポラリ テーブルとして使用されるメモリ内ハッシュテーブル。
高度に最適化されたクラス ライブラリから SQL 関数が実装されるため、最大限の速度が確保されます。通常は、クエリの初期化後にメモリ割り当てが行われることはありません。
MySQL コードは Purify(市販のメモリリーク検出システム)と Valgrind と呼ばれる GPL ツール(http://developer.kde.org/~sewardj/)を使用してテストされています。
クライアント/サーバまたは組み込み(リンク)バージョンとして使用可能です。単独のアプリケーションに組み込み(リンク)できるライブラリとしても提供されています。このようなアプリケーションは単一で、あるいはネットワーク環境の整っていない場所でも使用することができます。
データ タイプ:
多数のデータ タイプ:1、2、3、4、および 8
バイト長の符号付き/符号なし整数、FLOAT
、DOUBLE
、CHAR
、VARCHAR
、TEXT
、BLOB
、DATE
、TIME
、DATETIME
、TIMESTAMP
、YEAR
、SET
、ENUM
、および
OpenGIS 空間型。章?10. データタイプ
を参照してください。
固定長および可変長のレコード。
コマンドと関数:
クエリの SELECT
節および
WHERE
節での演算子と関数の完全なサポート。たとえば、次のように使用することができます。例
:
mysql>SELECT CONCAT(first_name, ' ', last_name)
->FROM citizen
->WHERE income/dependents > 10000 AND age > 30;
SQL の GROUP BY
節および
ORDER BY
節の完全なサポート。グループ関数(COUNT()
、COUNT(DISTINCT
...)
、AVG()
、STD()
、SUM()
、MAX()
、MIN()
、そして
GROUP_CONCAT()
)のサポート。
標準の SQL 構文および ODBC 構文での LEFT
OUTER JOIN
および RIGHT OUTER
JOIN
のサポート。
標準 SQL で必要な、テーブルおよびカラムにおけるエイリアスのサポート。
DELETE
、INSERT
、REPLACE
、および
UPDATE
変更された(影響を受けた)レコードの数を返す。
サーバに接続する際にフラグを設定することで、代わりに一致したレコードの数を返すことも可能です。
MySQL 固有の SHOW
コマンドを使用すると、データベース、テーブル、およびインデックスに関する情報を取得することができます。MySQL
5.0 では、INFORMATION_SCHEMA
データベースのサポートも、標準SQLに基づき追加されています。
EXPLAIN
コマンドを使用すると、オプティマイザによるクエリの解決方法を決定することができます。
関数名は、テーブル名やカラム名と衝突しません。例、ABS
は有効なカラム名である。関数呼び出しで、関数名とその後に続く
‘(
’
との間にスペースを使用できない点が唯一の制限事項です。項8.3. 「MySQLでの予約語の扱い」
を参照してください。
同ステートメント内のさまざまなデータベースのテーブルを参照することができます。
セキュリティ:
非常に柔軟で安全な権限およびパスワード システム。ホストベースの検証が可能です。
サーバに接続する際にすべてのパスワード トラフィックが暗号化されるので、パスワードは安全です。
拡張性と範囲:
大規模なデータベースを処理します。当社は、MySQL サーバを使用して 50,000,000 レコードが格納されたデータベースを処理しています。また、MySQL サーバを使用して 60,000 テーブル、約 5,000,000,000 レコードを処理しているユーザもいます。
各テーブルで最高
64個のインデックスが使用可能です。(MySQL
4.1.2では32個)。各インデックスは、1 から 16
個のカラムまたはカラムの一部で構成されます。インデックスの最大幅は
1000 バイトである(これは、MySQL
サーバのコンパイル時に変更可能である)。(InnoDB
では 767) MySQL 4.1.2 では 500
が限度でした。インデックスでは、CHAR
、VARCHAR
、BLOB
、あるいは
TEXT
型のカラムのプリフィックスを使用することができます。
接続性:
クライアントは複数のプロトコルを使用して MySQL に接続できます。
クライアントは、あらゆるプラットフォームで TCP/IP ソケットを使用して MySQL サーバに接続することができます。
WindowsNT ファミリ(NT、2000、XP、2003、または
Vista) の Windows システムでは、サーバが
--enable-named-pipe
オプションで起動された場合、クライアントは名前付きパイプを使用して接続することができます。
MySQL 4.1以降では、--shared-memory
オプションで起動されていれば Windows
のサーバは共有メモリコネクションもサポートされます。クライアントは
--protocol=memory
オプションを使用して共有メモリで接続できます。
Unix システムでは、Unix ドメイン ソケット ファイルを使用して接続することができます。
MySQL クライアント プログラムはさまざまな言語で記述できます。C 言語で記述されたクライアントライブラリは C、C++、あるいは C バインディングを提供するどの言語でも提供されています。Eiffel、Java、Perl、PHP、Python、Ruby、Tcl、そして他言語での API が提供されています。章?23. APIとライブラリー を参照してください。
C、C++、Eiffel、Java、Perl、PHP、Python、Ruby、そして Tcl の API が提供されています。よって、MySQL のクライアントがさまざまな言語で記述できます。章?23. APIとライブラリー を参照してください。
Connector/ODBC (MyODBC) インタフェースによって、ODBC (Open-DataBase-Connectivity)接続を使用するクライアントプログラムに MySQL サポートが提供されます。たとえば、MS Access を使用して MySQL サーバに接続することができます。クライアントは、Windows と Unix のどちらで実行されていてもかまいません。MyODBC ソースが使用可能です。他の多くの機能と同様に、ODBC 2.5 のすべての機能がサポートされます。章?24. MySQL コネクタ を参照してください。
Connector/J interface は JDBC 接続を使用する Java クライアント プログラムの MySQL サポートを提供しています。 クライアントは、Windows と Unix のどちらで実行されていてもかまいません。Connector/J ソースが使用可能です。章?24. MySQL コネクタ を参照してください。
MySQL Connector/NET は、開発者に MySQL 上で安全性の高い高性能データ接続性を要する NET アプリケーションの作成を容易に行えるようにします。要求される ADO.NET インターフェースを実行し、ADO.NET アウェアツールに統合します。開発者は .NET 言語を選択してアプリケーションを作成できます。MySQL Connector/NET は 100% C# で記述され、完全にマネージされた ADO.NET ドライバです。章?24. MySQL コネクタ を参照してください。
ローカライズ:
サーバからクライアントへ多数の言語でエラー メッセージを送信することができます。項4.10.2. 「英語以外のエラーメッセージ」 を参照してください。
latin1
(cp1252)、german
、big5
、ujis
、などのさまざまなキャラクタセットの完全なサポート。例えば、スカンジナビア語の文字
‘a
’、‘a
’
および ‘o
’
をテーブル名やカラム名で使用することができます。このオプションは
MySQL MySQL 4.1. 以降で利用できます。
すべてのデータが、選択したキャラクタ セットで保存されます。
ソートは、選択したキャラクタ
セットに基づいて行われます(デフォルトは
latin1
とスウェーデン語によるソート)。これは、MySQL
サーバの起動時に変更することができます。非常に高度なソートの例については、チェコ語のソートコードを参照してください。MySQL
サーバではさまざまなキャラクタ
セットがサポートされており、コンパイル時および実行時に指定することができます。
MySQL 4.1,以降、サーバのタイム ゾーンは大幅に変更可能で、各クライアントは自身のタイム ゾーンを指定できます。 項4.10.8. 「MySQL サーバのタイム ゾーン サポート」.
クライアントとツール:
MySQL AB は複数のクライアント/ユーティリティ プログラムを提供しています。これらの中には mysqldump や mysqladmin といったコマンド ライン プログラム、そして MySQL Administrator や MySQL Query Browser などのグラフィック プログラムも含まれます。
MySQL
サーバには、テーブルのチェック、最適化、および修復を行う
SQL
ステートメントのサポートが組み込まれています。これらのステートメントは、mysqlcheck
クライアントを介してコマンド
ラインから使用可能です。また、MySQL
には、MyISAM
テーブルでこれらの操作を実行するための
myisamchkという非常に高速なコマンド
ライン
ユーティリティが組み込まれています。章?7. クライアントプログラムとユーティリティ
プログラム
を参照してください。
--help
または -?
オプションを指定して呼び出すと、すべての
MySQL
プログラムでオンライン ヘルプを参照することができます。
このセクションでは、開発ロードマップの概略、現在のリリース シリーズ(5.1)にみられる新機能の概略、そして次期リリース シリーズ(5.2)にみられる追加事項や変更事項についての概略を述べます。
本マニュアル(5.1)でカバーされているリリース シリーズのグレードはbetaです。グレードについての詳しい情報は、項2.1.2.1. 「インストールする MySQL のバージョンの選択」 を参照してください。
次期リリース シリーズにアップグレードする前に、項2.11. 「MySQL のアップグレード」 にある注意事項をチェックしてください。
次の表は、最も要望があった機能の一部についての計画をまとめたものです。
機能 | MySQL シリーズ |
Unions | 4.0 |
R-trees | 4.1 (MyISAM ストレージ エンジン用) |
サブクエリ | 4.1 |
カーソル | 5.0 |
ストアド プロシージャ | 5.0 |
トリガ | 5.0および5.1 |
ビュー | 5.0 |
XA トランザクション | 5.0 |
イベント スケジューラ | 5.1 |
パーティション | 5.1 |
プラグイン API | 5.1 |
行ベースのレプリケーション | 5.1 |
サーバ ログ テーブル | 5.1 |
外部キー | 5.2 (InnoDB については3.23で実装済み) |
以下の機能が MySQL 5.1 に追加されました。
パーティション:この機能では、テーブル作成時に設定されたルールに従い、ファイル
システムに渡って各テーブルのポーションを分散することが可能になります。結果として、同一テーブルの異なるポーションが異なる場所に独立テーブルとして保存されますが、ユーザの観点からは、分割されたテーブルは依然として1つのテーブルとなります。
構文上、このことは新しい拡張数値を
CREATE TABLE
、ALTER
TABLE
そして EXPLAIN ...
SELECT
ステートメントに対して実行します。MySQL
5.1.6 以降は、テーブルの分割クエリとして
パーティション
プルーニング
が利用できます。この結果、テーブルを分割させない場合の同じクエリと比較して、はるかに高速でクエリの実行が可能となるケースもあります。この機能に関してさらに詳しい情報を知りたい場合は、章?15. パーティショニング
を参照してください。(執筆: Mikael Ronstrom)
行ベースのレプリケーション:MySQL におけるレプリケーション機能は本来、マスタからスレーブまでSQLステートメントの伝播に基づいて行われていました。これは、ステートメントベースのレプリケーション と呼ばれています。MySQL 5.1.5 以降、レプリケーションのためにもう1つのベースが利用できるようになりました。これは、行ベースのレプリケーション と呼ばれています。スレーブに SQL ステートメントを送る代わりに、マスタは各テーブルの行がどのように影響を受けるかを指定するバイナリ ログへのイベントを書き込みます。MySQL 5.1.8 以降では、3つ目のオプションが利用できます。組み合わせ です。これは、デフォルトではステートメントベースのレプリケーションが利用され、ある特定の場合にのみ行ベースのレプリケーションに切り替わるものです。詳しくは 項5.1.2. 「レプリケーション フォーマット」 を参照してください。(執筆: Lars Thalmann、 Guilhem Bichot、 Mats Kindahl)
プラグインAPI:MySQL 5.1 では、サーバの再起動をしなくても、ランタイムに様々なコンポーネントのロード/アンロードを可能にするとてもフレキシブルなプラグイン API も追加でサポートしています。実行が終了していなくても、プラグイン フルテキスト パーサ は実行内容の最初のステップとなります。この結果、ユーザは、PDF ファイルやその他の文書フォーマットのような任意データにおいてフルテキスト検索機能を可能にすることで、インデックス テキストの入力フィルタを実行できるようになります。プレ パーサ フル テキスト プラグインは、テキストの実効パーシングおよび抽出を行い、MySQL のビルトイン フル テキスト検索にそれを渡します。詳しくは 項25.2. 「The MySQL Plugin Interface」 を参照してください。(執筆: Sergey Vojtovich)
イベント
スケジューラ:MySQL
イベントは、スケジュールに従って実行するタスクです。1つのイベント作成時は、1つかそれ以上の正規インタバルで実行される、同じく1つかそれ以上の
SQL
ステートメントを含む名前つきデータベース
オブジェクトを作成していることになります。このオブジェクトは、指定されたデータや時間で開始および終了するものです。概念として、このことはUnixの
crontab
(「コロンジョブ」
としても知られる)や、Windows のタスク
スケジューラの考え方に似ています。詳しくは
章?19. Event Scheduler
を参照してください。(執筆: Andrey Hristov)
サーバ ログ
テーブル:MySQL 5.1
以前では、サーバはログ
ファイルに一般クエリ ログや低速クエリ
ログ エントリーを書き込みます。MySQL 5.1
以降では、サーバのこういったログ書き込み機能はより柔軟性のあるものとなります。ログのエントリはログ
ファイル (上記のように) あるいは
general_log
および
mySQL
データベースの
slow_log
に書き込まれます。ロギングが有効になると、ディスティネーションのいずれかまたは両方が選択されます。
--log-output
オプションはディスティネーションあるいはログ出力のディスティネーションを管理します。詳しくは
項4.11.1. 「一般クエリとスロー クエリのログ出力先の選択」
を参照してください。(執筆: Petr Chardin)
インスタンス
マネージャー(IM)
に新しい機能が追加されました。SHOW
はすべてのログ
ファイルをリストアップし、instance_name
LOG FILESSHOW
は指定ログファイルの一部を検索し、instance_name
LOG {ERROR | SLOW |
GENERAL} size
SET
はオプションを指定値に設定して構成ファイルに書き込みます。詳しくは
項4.4. 「mysqlmanager ? MySQL Instance Manager」
を参照してください。(執筆: Petr Chardin)
instance_name
.option_name
=option_value
アップグレード プログラム:mysql_upgrade プログラム(MySQL 5.1.7 以降で利用可能)では、MySQL サーバの現バージョンとの不適合性を調べるためにすべての現存テーブルがチェックされます。また、必要であればそれらの修復も行われます。このプログラムは各MySQLのアップグレードに対して起動されなければなりません。詳しくは 項4.5.4. 「mysql_upgrade ? MySQL アップグレードのテーブル チェック」 を参照してください。(執筆: Alexey Botchkov、Mikael Widenius)
MySQLクラスタ間のレプリケーションがサポートされるようになりました。MySQLクラスタと非クラスタデータベース間のレプリケーションも可能になりました。項14.10. 「MySQL Cluster レプリケーション」 を参照してください。
MySQLクラスタディスクデータ:5.1.6以前のMySQLバージョンでは、NDBCluster
ストレージエンジンは必ずメモリ内に保存されていましたが、MySQL
5.1.6からはディスク上のクラスタデータ(ただし、インデックスではない)に保存されることが可能になりました。このことで、MySQLクラスタは以前よりも少ないハードウェア(RAM)で拡大できるようになりました。項14.11. 「MySQL Cluster ディスク データ ストレージ」
を参照してください。
ディスクデータの実行では、大量データ(テラバイト値域)の保存時に、高速ノード再起動のための新「no-steal」修復アルゴリズム も実行されます。
MySQLクラスタに対するオンラインADD
INDEX
およびDROP
INDEX
:テーブルへのインデックス追加と削除は、MySQLクラスタの前バージョンよりも、NDB
ストレージエンジンを使用したほうが遥かに高速で処理されます。これは、NDB
がテーブルを再作成する必要がないかわりにこれらのスキーマを現存テーブルに直接変換できるため、実現可能となっています。
MySQLクラスタ上での改良バックアップ実行:クラスタバックアップ中に単一データノードに生じる障害が、MySQLクラスタの前バージョンのように、アボートするために完全バックアップを起こすことはありません。
テーブルスペースのバックアップ:mysqldump機能では、テーブルスペースのダンプオプションがサポートされています。-Y
または--all-tablespaces
を使用して、この機能を有効にしてください。
INFORMATION_SCHEMA
に対する改良:MySQL
5.1では、メタデータ
データベースでさらに詳しい情報が提供されています。そのデータベース上の新しいテーブルには、FILES
、EVENTS
、PARTITIONS
、PROCESSLIST
、ENGINES
そしてPLUGINS
が含まれています。
XML 機能:ExtractValue()
は、作成されたXPath表現に適合するXMLフラグメントの内容を返します。UpdateXML()
は、XMLフラグメントから選択された要素を、ユーザが第二XMLフラグメント(これもユーザが与えたもの)を与えたXPath表現に置換します。そして、修正XMLを返します。詳しくは
項11.9. 「XML 関数」
を参照してください。(執筆: Alexander Barkov)
ロードエミュレータ:mysqlslapプログラムは、MySQLサーバにクライアントのロードをエミュレートし、各ステージのタイミングを報告するよう設定されています。それは、複数のクライアントがサーバにアクセスしているかのように働きます。詳しくは 項7.16. 「mysqlslap ? クライアント負荷エミュレーション」 を参照してください。(執筆: Patrick Galbraith, Brian Aker)
以下の機能がMySQL 5.2に追加もしくは変更されることが計画されています。このセクションは、MySQL 5.2開発が初期段階にある場合に変更される可能性があります。
次の概念は、MySQL 5.2ではほとんど扱われないか、もしくはなくなる可能性があります。他のオプションがあれば、それを利用するためにアプリケーションをアップデートする必要があります。
table_type
変数
(storage_engine
の使用)
log_bin_trust_routine_creators
変数(log_bin_trust_function_creators
の使用)
TIMESTAMP(
:N
)N
のディスプレイ幅を指定できます。(N
は使用しない)
ストレージエンジンを指定するためのTYPE
テーブルオプション(ENGINE
を使用する)
SHOW TABLE TYPES
SQLステートメント(SHOW
ENGINES
を使用する)
SHOW INNODB STATUS
SQLステートメント(SHOW ENGINE INNODB
STATUS
を使用する)
SHOW MUTEX STATUS
SQLステートメント(SHOW ENGINE INNODB
MUTEX
を使用する)
SHOW LOGS
SQLステートメント
LOAD TABLE FROM MASTER
SQLステートメント
RESTORE TABLE
SQLステートメント
BACKUP TABLE
SQLステートメント
このセクションでは、MySQL メーリング リスト、ユーザ フォーラム、IRC など、役に立つと思われる情報を提供します。
このセクションでは MySQL メーリング リストの概要を説明するとともに、メーリング リストの使用ガイドラインを提供します。メーリング リストを購読すると、メーリング リストに投稿されたすべてのメッセージを電子メールとして受け取ることができます。自分の質問や回答をメーリング リストに送信することもできます。
このセクションに記載されているメーリング リストの購読を開始または購読を中止する場合には、http://lists.mysql.com/ にアクセスしてください。ほとんどのメーリング リストは、個別のメッセージを得られる通常版、または一日おきにひとつの大きなメッセージを受け取れるダイジェスト版から選択できます。
購読または購読中止に関するメッセージはいずれのメーリング リストにも送信しないでください。 送信した場合、そのメッセージを購読する多くのユーザへ自動的に配信されてしまいます。
あなたのローカル サイトには MySQL メーリング
リストに登録した多くの購読者がいるかもしれません。その場合、lists.mysql.com
から送信されたメッセージは、あなたのローカルなメーリング
リストから受信できるように用意されている場合があります。その際は、ローカルの
MySQL
リストへの追加または削除については、あなたのシステム管理者にお問い合わせください。
メール プログラム内の個別のメール
ボックスにメーリング
リストが送信されるようにするには、フィルタをメッセージヘッダから判別するように設定してください。List-ID:
または Delivered-To:
ヘッダを使用して、リストのメッセージを識別することができます。
MySQL メーリング リストは以下のとおりです。
announce
このリストは、新しいバージョンの MySQL および関連するプログラムの通知に使用されます。これは、サイズの小さいリストであり、すべての MySQL ユーザは購読するべきです。
mysql
これは MySQL の一般的な議論に使用される主要なリストです。議題によっては、より細分化されたメーリング リストで議論を行ったほうがよい場合があります。適切でないリストに投稿すると、回答が得られないことがあります。
バグ
これは、MySQL の最新リリース以降に報告された問題を常に把握しておきたいユーザや、バグの検出と修正の過程に積極的に参加したいユーザのためのリストです。詳細は 項1.7. 「質問またはバグの報告」 を参照してください。
internals
このリストは MySQL のプログラミングに携わる人を対象とします。MySQL の開発およびパッチ投稿に関する議論を行うフォーラムでもあります。
mysqldoc
このリストは MySQL の文書に携わる人、すなわちMySQL AB の社員、翻訳者、その他のコミュニティー会員を対象とします。
ベンチマーク
このリストは、パフォーマンスに関する問題に関心がある人を対象としています。データベースのパフォーマンス(MySQL に限らない)に関する議論のみでなく、カーネル、ファイルシステム、ディスクシステムのパフォーマンスなど、より広範なカテゴリも含まれます。
packagers
このリストは、MySQL のパッケージと配布に関する議論に使用されます。これは、MySQL のパッケージに関するアイデアを交換し、サポートするすべてのプラットフォームとオペレーティングシステム上でできる限り同じような MySQL の外観と操作性を確保する目的のため、配布管理者によって使用されるフォーラムです。
java
このリストは、MySQL サーバと Java に関する議論に使用されます。ほとんどが、MySQL Connector/J などの JDBC ドライバに関する議論に使用されています。
win32
このメーリングリストは、Microsoft のオペレーティングシステム(Windows 9x/Me/NT/2000/XP/Server 2003 など)で実行される MySQL ソフトウェアに関するすべてのトピックに使用されます。
myodbc
このメーリングリストは、ODBC を使用した MySQL サーバへの接続に関するすべてのトピックに使用されます。
gui-tools
このメーリングリストは MySQL のグラフィカル
ユーザ インタフェース、たとえば MySQL
Administrator
や MySQL Query
Browser
などについて使用されます。
cluster
このメーリングリストは MySQL クラスタの議論に使用されます。
dotnet
このメーリングリストは MySQL サーバおよび .NET プラットフォームに関する議論に使用されます。ほとんどがMySQL Connector/Netに関連する議論です。
plusplus
このリストは、MySQL への C++ API を使用したプログラミングに関するすべてのトピックに使用されます。
perl
このリストは、MySQL
のDBD::mysql
を使用した Perl
サポートに関するすべてのトピックに使用されます。
質問に対する回答が MySQL メーリングリストから得られなかった場合、MySQL AB から有料サポートを受ける方法があります。この方法は、MySQL の開発者と連絡を直接取ることができます。
以下は、英語以外の MySQL メーリング リストです。これらのリストは MySQL AB による運営ではありません。
<mysql-france-subscribe@yahoogroups.com>
フランス語のメーリングリスト。
韓国語のメーリングリスト。購読するには、このメーリングリストに
subscribe mysql your@email.address
と書いた電子メールを送信してください。
<mysql-de-request@lists.4t2.com>
ドイツ語のメーリングリスト。購読するには、このメーリングリストに
subscribe mysql-de your@email.address
と書いた電子メールを送信してください。このメーリングリストに関する詳細な情報は、http://www.4t2.com/mysql/を参照してください。
<mysql-br-request@listas.linkway.com.br>
ポルトガル語のメーリングリスト。購読するには、このメーリングリストに
subscribe mysql-br your@email.address
と書いた電子メールを送信してください。
スペイン語のメーリングリスト。購読するには、このメーリングリストに
subscribe mysql your@email.address
と書いた電子メールを送信してください。
HTML モードがオンになっているブラウザからメールメッセージを投稿しないでください。多くのユーザはブラウザでメールを読みません。
メーリングリストの質問に回答するとき、多数のユーザにとても興味深いと思われる回答は、質問した個人に直接返信する代わりにメーリングリストに投稿しても構いません。その場合、元の投稿者以外のユーザにも役立つように、包括的な回答をするようにしてください。メーリングリストに投稿する際には、回答が前の回答と重複していないことを確認してください。
質問の重要な部分を回答へ要約するように努めてください。元のメッセージ全体を引用する必要はありません。
もし回答があなた個人に送られた場合、そしてメーリングリストではない場合、回答を要約してメーリングリストに載せることは、よいエチケットです。そうすれば他の人も、あなたが得たトラブル解決方法を共有できます。
フォーラムは重要なコミュニケーションの場です。場所はhttp://forums.mysql.comです。多くのフォーラムに参加可能です。以下のカテゴリーがあります。
Migration (移入)
MySQL Usage (MySQL の使い方)
MySQL Connectors (MySQL コネクター)
Programming Languages (プログラム言語)
Tools (ツール)
3rd-Party Applications (サード パーティーによるアプリケーション)
Storage Engines (ストレージ エンジン)
MySQL Technology (MySQL テクノロジ)
SQL Standards (SQLの標準化)
Business (ビジネス)
さまざまな MySQL メーリング リストやフォーラムに加え、IRC (インターネット リレー チャット)にも経験豊富なコミュニティがあります。以下は、当社が現在把握している最もすぐれたネットワーク/チャネルです。
freenode (サーバは http://www.freenode.net/ を参照してください。)
#mysql
MySQL
に関する質問が中心ですが、他のデータベースや
SQL に関する質問も受け付けています。MySQL と
PHP、Perl、C
言語の組み合わせに関する質問も行われています。
IRC ネットワークに接続するための IRC
クライアントソフトウェアを探している場合には、xChat
(http://www.xchat.org/)を参照してください。X-Chat(GPL
ライセンス)は、Unix および Windows
プラットフォームで使用することができます。(無料Windows版
X-Chat
は次の場所から入手できます。http://www.silverex.org/download/)
問題に対する解決策が新しいバージョンにすでに組み込まれている可能性がありますので、バグがすでに報告/解決されているかどうかを確認してください。
このサイトhttp://dev.mysql.com/doc/でマニュアルを検索することができます。マニュアルは、常に最新の状態にしておくために、新しく見つかった問題に対する解決策によって頻繁に更新されています。問題に対する解決策が新しいバージョンにすでに組み込まれている可能性が高いので、変更履歴に関する付録(http://dev.mysql.com/doc/mysql/en/news.html)は特に便利です。
SQL
ステートメントに対するパースエラーが生じた場合は、構文を念入りにチェックしてください。その構文に問題が見当たらなければ、MySQLの最新バージョンサーバがその構文をサポートしていない可能性が高くなります。最新のバージョンでマニュアルが使用された構文をカバーしていない場合、MySQL
サーバはそのステートメントをサポートしません。この場合、ご自身でその構文を実行されるか、もしくは<licensing@mysql.com>
宛てに電子メールを送り、サポートについてお問い合わせください。
マニュアルがその構文をカバーしているにも関わらず、MySQLが旧バージョンサーバの場合、MySQLの変更履歴を調べいつその構文が実行されたのかを確認してください。この場合、MySQLサーバへ新しくアップグレードするという選択肢もあります。
一般的な問題の解決法については以下を参照してください。項B.1. 「Problems and Common Errors」。
バグデータベースhttp://bugs.mysql.com/ を検索して、バグがすでに報告/解決されているかどうかを確認します。
次の場所で MySQL メーリングリストのアーカイブを検索します。http://lists.mysql.com/.詳細は 項1.6.1. 「MySQL メーリング リスト」 を参照してください。
また、http://www.mysql.com/search/を使用して、MySQL AB Web サイトにある Web ページすべて(マニュアルを含む)を検索することもできます。
マニュアルやアーカイブで回答を見つけることができなかった場合、ローカルの MySQL の専門家とともに調べてください。それでも質問に対する回答を見つけることができなかった場合は、次のセクションに記載されているガイドラインに従って MySQL メーリングリストにメールをお送りください。
通常バグを報告する場合、バグデータベースのアドレスhttp://bugs.mysql.com/を参照してください。当社のバグデータベースは公開されているので、すべてのユーザが 参照および検索することができます。システムにログインすると、新しいレポートを入力することもできます。 Webがアクセスできる環境が整っていない場合、この章の最後に記載のmysqlbugスクリプトを使用してバグレポートを作成することができます。
http://bugs.mysql.com/にあるバグデータベースにバグが報告されると、変更履歴にてどのバージョンで修正されたか確認できます。
MySQL で重大なセキュリティ
バグを見つけた場合は、<security@mysql.com>
に電子メールをお送りください。
他のユーザと問題について話し合う場合、MySQL メーリング リストの一部を利用することもできます。 項1.6.1. 「MySQL メーリング リスト」.
正確なバグ レポートを書くのは時間がかかるものですが、レポートを一度で済ませることで、報告者と弊社、双方の時間を節約することができます。そのバグの完全なテスト ケースを含むバグ レポートを提供していただければ、次回のリリースではその問題を修正できる可能性が高くなります。このセクションでは、ユーザの時間短縮と効果的な情報提供のため、レポートの正しい書き方を紹介します。このセクションを注意深く読み、ここに記載されている全ての情報がユーザレポートに含まれているか、確認してください。
できれば、MySQL
サーバの最新の製品版または開発版を使用して問題をテストしてから投稿してください。だれもが記載されているテストケースで
mysql test <
script_file
を使用するだけでバグを再現したり、バグレポートに含まれているシェルまたは
Perl
スクリプトを実行したりすることができるようにする必要があります。弊社で再現が可能なバグであれば、次回の
MySQL
リリースで修正される可能性が高くなります。
問題に関する適切な説明がバグレポートに記載されていると、最も効果的です。そのため、問題につながったすべての操作の適切な例を挙げ、問題自体を詳細に記述してください。最も効果的なレポートは、バグや問題を再現する方法を示す詳細な例が記載されたものです。詳細は Making a Test Case If You Experience Table Corruption を参照してください。
情報が多すぎるメッセージに対応することはできますが、少なすぎるメッセージに対応することはできません。多くの場合、問題の原因がわかっていると思い、細部を重要でないと考えるため、事実を省略してしまいます。記載するかどうかを迷ったときは、記載することをお勧めします。最初に十分な情報を記載していなかったために再度質問して、回答を待たなければならなくなるよりも、レポートに数行を追加する方が、はるかに時間が節約される上に、煩わしくありません。
バグレポートで最もよくある誤りは、(a) 使用している MySQL ディストリビューションのバージョン番号を記載していない、(b) MySQL サーバがインストールされているプラットフォームの説明(プラットフォームの種類およびバージョン番号を含む)が十分でないというものです。これは非常に重要な情報なので、ほとんどの場合、この情報が記載されていないバグレポートは役に立ちません。「なぜうまく作動しないのか ? 」 という質問が頻繁に寄せられます。その場合、要求した機能がその MySQL バージョンに実装されていなかったり、レポートに記載されているバグが新しい MySQL バージョンですでに修正されていたりすることがあります。エラーがプラットフォーム依存である場合もあります。そのような場合、オペレーティングシステムやプラットフォームのバージョン番号を知らないで問題を修正することはほとんど不可能です。
また、コンパイラが問題に関連している場合は、コンパイラに関する情報も記載してください。ユーザがコンパイラのバグを見つけると、MySQL 関連の問題であると考えることがよくあります。ほとんどのコンパイラは常に開発中なので、バージョンごとに改良されています。題がコンパイラに関連するものであるかどうかを判断するには、使用しているコンパイラを知る必要があります。コンパイルに関するすべての問題はバグと見なし、適宜報告してください。
プログラムでエラーメッセージが生成された場合、そのメッセージをレポートに記載することが非常に重要です。プログラムを使用するアーカイブから情報を検索しようとする場合、報告されたエラーメッセージがプログラムで生成されたものと正確に一致している方が効果的です。(大文字小文字の違いにも注意してください。)エラーメッセージを覚えるのではなく、メッセージ全体をレポートにコピーして貼り付けてください。
MyODBC に関する問題がある場合、MyODBC トレースファイルを生成し、レポートともに送信してください。章?24. MySQL コネクタのMyODBCセクションをご参照ください。
レポートにmysqlコマンドラインツールが使用され、テストケースから長い出力クエリが含まれる場合、そのようなディスプレイの有効な幅を超える出力については、--vertical
オプション(または
\G
ステートメント終端記号)を使用する必要があります。
このセクションに後述されるEXPLAIN
SELECT
例では\G
の使用方法を詳しく述べます。
レポートには以下の情報を記載してください。
使用している MySQL
ディストリビューションのバージョン番号(MySQL
バージョン
5.0.19など)。実行しているバージョンを確認するには、mysqladmin
versionを実行します。mysqladminは、MySQL
インストールディレクトリ下の
bin
ディレクトリにあります。
問題が発生したマシンの製造元とモデル。
オペレーティングシステムの名前とバージョン。Windows
を使用している場合、名前とバージョン番号を取得するには、通常
``マイ コンピュータ''
アイコンをダブルクリックし、「ヘルプ/バージョン情報」メニューをプルダウンします。ほとんどのオペレーティングシステムでは、この情報を取得するには、Unix
コマンド uname -a
を実行します。
メモリ(実メモリと仮想メモリ)の量が関連することもあります。関連していると思われる場合は、これらの値を記載します。
MySQLソフトウェアのソースディストリビューションを使用している場合、使用しているコンパイラの名前とバージョン番号が必要です。バイナリディストリビューションを使用している場合は、ディストリビューション名が必要です。
コンパイル時に問題が発生した場合、正確なエラーメッセージ、およびエラーが発生したファイル内の問題のあるコード付近の数行のコンテキストを記載します。
mysqldが停止した場合、mysqldのクラッシュの原因となったクエリも報告する必要があります。通常、ログを有効にして mysqldを実行すると、mysqldがクラッシュした後でこれを検出することができます。 詳細は Using Server Logs to Find Causes of Errors in mysqld を参照してください。
データベーステーブルが問題に関連している場合、SHOW
CREATE TABLE
からの出力を記載します。これを行うのは非常に簡単ですが、データベース内のテーブルに関する情報を取得する強力な方法です。この情報は、発生した状況と同じ状況を再現する際に役立ちます。
db_name
.tbl_name
問題発生時のSQLモードも有効な情報になります。sql_mode
システム変数値を報告してください。
保存されたプロシージャ、ファンクション、そしてトリガオブジェクトの関連するsql_mode
値は、そのオブジェクトが作成された際に有効だったものになります。保存されたプロシージャかファンクションに関して、SHOW
CREATE PROCEDURE
またはSHOW CREATE
FUNCTION
ステートメントは有効なSQLモードを示しています。また、これに関する情報に対してはINFORMATION_SCHEMA
クエリを利用することができます。
SELECT ROUTINE_SCHEMA, ROUTINE_NAME, SQL_MODE FROM INFORMATION_SCHEMA.ROUTINES;
トリガに対しては以下のステートメントが利用できます。
SELECT EVENT_OBJECT_SCHEMA, EVENT_OBJECT_TABLE, TRIGGER_NAME, SQL_MODE FROM INFORMATION_SCHEMA.TRIGGERS;
性能に関連するバグやSELECT
ステートメントに関する問題については、EXPLAIN
SELECT
...
の出力や、少なくともSELECT
ステートメントが生成する行の数も含んでください。関連する各テーブル毎に、SHOW
CREATE TABLE
からの出力もまた含んでください。状況について情報を提供できればできるほど、有効な手助けが可能となります。
tbl_name
下記はバグレポートの良い例です。mysqlコマンドラインツールを使ってステートメントが実行されています。読むのが困難なほど長い出力行に対して、\G
ステートメント終端記号がどのように使用されているか確認してください。
mysql>SHOW VARIABLES;
mysql>SHOW COLUMNS FROM ...\G
<output from SHOW COLUMNS>
mysql>EXPLAIN SELECT ...\G
<output from EXPLAIN>
mysql>FLUSH STATUS;
mysql>SELECT ...;
<A short version of the output from SELECT, including the time taken to run the query>
mysql>SHOW STATUS;
<output from SHOW STATUS>
mysqldの実行中にバグまたは問題が発生した場合、その異常を再現する入力スクリプトを提供します。このスクリプトには、必要なソースファイルを含める必要があります。スクリプトによって再現される状況が実際に発生した状況に近いほど、効果的です。再現可能なテストケースを作成できる場合は、バグレポートにアタッチメントとしてアップロードしてください。
スクリプトを提供できない場合は、少なくともmysqladmin variables extended-status processlistからの出力をメールに記載して、システムの動作に関する情報を提供する必要があります。
数行ではテストケースを再現できない場合や、テストテーブルが大きすぎてメーリングリストに送信できない場合(10
レコードを超えるテーブル)、mysqldumpを使用してテーブルをダンプし、問題を説明する
README
ファイルを作成する必要があります。
tarと gzipまたは
zipを使用してファイルの圧縮アーカイブを作成し、FTP
を使用してそのアーカイブを
ftp://ftp.mysql.com/pub/mysql/upload/に転送します。その後、バグデータベースhttp://bugs.mysql.com/に問題を入力します。
MySQL サーバでクエリによって正しくない結果が生成されたと思う場合、結果だけでなく、正しいと考える結果と、その考えの根拠を示す説明も記載します。 .
問題のサンプルを提供する際には、新しい名前を使用するよりも、実際の状況で使用している変数名やテーブル名などを使用するのが適切です。問題が、変数やテーブルの名前に関連している可能性があるためです。このようなケースはほとんどないと思われますが、後悔するよりも安全策をとるべきです。結局、実際の状況に基づいたサンプルを提供する方がユーザにとって簡単であると同時に、当社にとっても効率的です。データを他のユーザに公開したくない場合は、ftp を使用して ftp://ftp.mysql.com/pub/mysql/upload/に転送することができます。データが実際に最高機密で、当社にも公開したくない場合は、他の名前を使用したサンプルを提供することもできますが、これは最後の選択肢です。
可能な場合、関連するプログラムのすべてのオプションを記載します。たとえば、mysqldサーバを開始する際に使用したオプションや
MySQL
クライアントプログラムの実行に使用したオプションを記載します。mysqldやmysqlのようなプログラムのオプション、configureスクリプトのオプションは多くの場合、回答への手がかりとなり、非常に重要です。これらを記載することは、決して無駄ではありません。Perl
や PHP
などのモジュールを使用している場合は、それらの言語プロセッサーバジョン番号だけでなく、プログラムが使用するモジュールバージョンも同様に記載します。例えば、DBI
やDBD::mysql
を使用するPerl
スクリプトがある場合、Perl、DBI
、そしてDBD::mysql
バージョン番号を記載します。
質問が権限システムに関連する場合、mysqlaccessの出力、mysqladmin
reloadの出力、および接続しようとした際に表示されたすべてのエラーメッセージを記載します。権限をテストする際には、まず
mysqlaccessを実行します。その後、mysqladmin
reload
versionを実行し、問題が発生したプログラムに接続します。mysqlaccessは、MySQL
インストールディレクトリ下の
bin
ディレクトリにあります。
バグのパッチを作成した場合、それを含めます。ただし、当社はパッチだけを必要としているわけではありません。パッチによって修正されるバグを示すテストケースなどの必要な情報が記載されていない場合、当社はそのパッチを使用しません。当社がパッチに関連する問題を見つける場合もあれば、パッチをまったく理解できない場合もあります。そのような場合は、パッチを使用することはできません。
パッチの目的を正確に確認することができない場合、当社はそのパッチを使用しません。この場合、テストケースが役立つことになります。発生する可能性があるすべての状況がパッチによって処理されることを示す必要があります。パッチが機能しないボーダーラインケースが見つかった場合(それがまれなケースでも)、そのパッチは役に立たない可能性があります。
何がバグであるか、そのバグがなぜ発生するのか、そのバグが何に関連するのかを推測することは、通常、間違いです。MySQL チームでさえも、最初にデバッガを使用せずにそのようなことを推測して、バグの実際の原因を特定することはできません。
ユーザ自身で問題を解決しようとしたことを他のユーザがわかるように、リファレンスマニュアルやメールアーカイブを確認したことをバグレポートに記載します。
データが壊れている点が問題である場合や、特定のテーブルにアクセスした際にエラーが発生した場合、myisamchkまたは
CHECK TABLE
とREPAIR
TABLE
を使用して、まずテーブルをチェックしてから、修復を試みる必要があります。
詳細は 章?4. データベース管理
を参照してください。
Windows起動時、SHOW VARIABLES LIKE
'lower_case_table_names'
コマンドを使用してlower_case_table_names
値をベリファイしてください。
変数は、データベースおよびテーブル名の大文字/小文字をサーバがどのように扱うかに対して影響を与えます。ある値に対しての効果は項8.2.2. 「識別子の大文字/小文字区別」で説明されている通りです。
テーブルが頻繁に壊れる場合、その問題が発生する状況と理由を特定する必要があります。この場合、.err
ファイルに、発生した問題に関する情報が格納されていることがあります。詳しくは項4.11.2. 「エラー ログ」を参照してください。このファイル内の関連する情報をバグレポートに記載します。通常、更新の途中で
mysqldが停止されない限り、mysqld
によってテーブルが破壊されることはありません。
mysqldが停止した原因が特定されれば、当社はその問題の解決策をはるかに簡単に提供することができます。
詳細は 項B.1.1. 「How to Determine What Is Causing a Problem」
を参照してください。
可能な場合、最新バージョンの MySQL サーバをダウンロードしてインストールし、これによって問題が解決されるかどうかを確認します。MySQL ソフトウェアのすべてのバージョンが詳細にテストされているため、問題なく動作するはずです。すべてにおいて最大限の下位互換性が確保されているため、MySQL のバージョンを問題なく切り替えることができると当社は確信しています。 詳細は 項2.1.2. 「インストールする MySQL 配布版の選択」 を参照してください。
Webがアクセスできる環境が整っておらず、http://bugs.mysql.com/を参照してもバグレポートができない場合、この章の最後に記載のmysqlbugスクリプトを使用してバグレポート(もしくは他の問題に対するレポート)を作成することができます。mysqlbugは自動的に以下の情報を確認することでユーザのレポート作成を助けますが、大事な情報が欠如している場合は、メッセージに記載してください。mysqlbugはMySQLインストールディレクトリ(バイナリディストリビューション)内のscripts
ディレクトリ(ソースディストリビューション)とbin
ディレクトリで見つけることができます。
このセクションでは、MySQL と ANSI/ISO SQL 標準との関連を説明します。MySQL サーバには SQL 標準に対する多数の拡張機能があります。ここでは、それらの拡張機能と使用方法を説明します。また、MySQL サーバに不足している機能と、差異を解決する方法に関する情報も提供します。
SQL標準は1986年から発展し続けており、現在いくつかのバージョンがあります。本マニュアルでは、「SQL-92」 は 1992年にリリースされた標準に、「SQL:1999」 は 1999年にリリースされた標準に、そして 「SQL:2003」 は標準の現バージョンに対応しています。「SQL標準」や「標準SQL」といった言い回しは、常にSQL標準の現バージョンを意味します。
製品に関する当社の主な目標の 1
つは、速度や信頼性を犠牲にすることなく、SQL-99
標準への準拠に向けて開発を続けることです。大部分のユーザにとって
MySQL
サーバが大幅に使いやすくなるのであれば、当社は
SQL に対する拡張機能や SQL
以外の機能のサポートを積極的に追加します。HANDLER
インターフェースはこの方針の一例です。項12.2.3. 「HANDLER
構文」
を参照してください。
当社は、負荷が高い Web/ログの使用とミッションクリティカルな年中無休の使用の両方に対応するために、トランザクションデータベースと非トランザクションデータベースのサポートを継続します。
MySQL サーバは、小規模なコンピュータシステムで中規模のデータベース(1,000 万 ? 1 億行、または 1 テーブルあたり約 100 MB)を使用することを目的として最初から設計されました。テラバイト規模のデータベースでも適切に動作するとともに、ハンドヘルドデバイスや組み込み用途により適した小規模な MySQL をコンパイルできるように、MySQL サーバの拡張を続けます。MySQL サーバのコンパクトな設計によって、ソースツリーで競合することなく、これらのどちらの方向も実現することができます。
現時点では、リアルタイムのサポートは考えていません(ただし、レプリケーションサービスを使用して、すでに多くのことを実行することができます)。
MySQLでは、NDBCluster
ストレージエンジンの実装によって、有効性の高いデータベースクラスタがサポートされています。章?14. MySQL Cluster
を参照してください。
MySQL 5.1でW3C XPath標準のほとんどがサポートされることで、XML機能が提供されています。今後のMySQL開発の一部として、XMLへのサポートの充実を計画しています。項11.9. 「XML 関数」 を参照してください。
MySQLサーバは異なるSQLモードで機能し、これらのモードを各クライアントにそれぞれ適合させることができます。この機能では、各アプリケーションがサーバのオペレーティングモードをその要求に合わせることができます。
SQLモードでは、MySQLがどのSQL構文をサポートすべきかまたはどの種類のデータバリデーションを実行すべきか、といったサーバオペレーション分野が管理されています。つまり、モードを定義することにより、異なる環境で MySQL を使用でき、MySQL を別のデータ ベース サーバと併用できるようになります。
--sql-mode="
オプションでmysqldを起動させると、デフォルトのSQLモードが設定できます。MySQL
4.1からは、mode_value
"SET [SESSION|GLOBAL]
sql_mode='
ステートメントを使用してmode_value
'sql_mode
システム変数を設定することで、ランタイムのモード変更もできます。
SQLモードの設定に関するさらに詳しい情報は、項4.2.6. 「SQL モード」を参照してください。
mysqldを使用して、--ansi
スタートアップオプションでANSIモードを実行させることができます。ANSI
モードでサーバを実行するのは、以下のオプションを指定してサーバを起動するのと同じことです
--transaction-isolation=SERIALIZABLE --sql-mode=ANSI
MySQL 4.1 以降では、次の 2 つのステートメントで同じ動作を実現することができます。
SET GLOBAL TRANSACTION ISOLATION LEVEL SERIALIZABLE; SET GLOBAL sql_mode = 'ANSI';
sql_mode
システム変数値は'ANSI'
に設定されることで、ANSIモードに関連するすべてのSQLモードオプションに設定されます。結果を確認するには、以下を実行します。
mysql>SET GLOBAL sql_mode='ANSI';
mysql>SELECT @@global.sql_mode;
-> 'REAL_AS_FLOAT,PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE,ANSI'
--ansi
を指定してANSIモードでサーバを実行することと、SQLモードを'ANSI'
に設定することは、同じではありません。--ansi
オプションはSQLモードに影響を与え、トランザクション分離レベルも設定します。SQLモードを'ANSI'
に設定しても、分離レベルに影響はありません。
項4.2.2. 「コマンド オプション」および項1.8.2. 「SQLモードの選択」を参照してください。
MySQLサーバには、他の SQL データベースにはない拡張機能があります。それらの拡張機能を使用した場合、他の SQL サーバにコードを移植できなくなるので注意してください。場合によっては、MySQL 拡張機能を含むコードを記述しても、次の形式のコメントを使用することで移植することができます。
/*! MySQL-specific code
*/
その場合、MySQL サーバでは、他の MySQL
ステートメントと同様にコメント内のコードが解析および実行されますが、他の
SQL
サーバでは拡張機能が無視されます。例えば、MySQLサーバは次のステートメント内のSTRAIGHT_JOIN
キーワードを認識しますが、他のサーバでは認識されません。
SELECT /*! STRAIGHT_JOIN */ col1 FROM table1,table2 WHERE ...
‘!
’の後ろにバージョン番号を追加すると、MySQL
バージョンが、使用されているバージョン番号以降の場合にのみ、構文が実行されます。
バージョン 3.23.02
以降を使用している場合、MySQL サーバで
次のコメント内のTEMPORARY
キーワードが使用されます。
CREATE /*!32302 TEMPORARY */ TABLE t (a INT);
以下は、MySQL 拡張機能の一覧です。
ディスク上のデータ構成
MySQL サーバでは、各データベースは MySQL データディレクトリ下のディレクトリに、データベース内のテーブルはデータベースディレクトリ内のファイル名にマップされます。これには、次のような意味があります。
ほとんどの Unix システムのようにファイル名で大文字と小文字が区別されるオペレーティングシステム上の MySQL サーバでは、データベース名およびテーブル名は大文字と小文字を区別されます。項8.2.2. 「識別子の大文字/小文字区別」 を参照してください。
MyISAM
ストレージエンジンを使用して、テーブルのバックアップ、名前の変更、移動、削除、およびコピーを行うことができます。たとえば、MyISAM
テーブルの名前を変更するには、テーブルに対応する.MYD
、.MYI
、および.frm
ファイルの名前を変更します。(ただし、RENAME
TABLE
やALTER TABLE ...
RENAME
を使用して、サーバにファイル名を変更させるほうが好ましいでしょう。)
データベースとテーブル名は、パスネーム分離文字(‘/
’や‘\
’)を含むことはできません。
一般言語構文
デフォルトでは、文字列は‘'
’だけでなく、‘"
’や‘'
’のいずれかでも囲むことができます。(ANSI_QUOTES
SQLモードが有効な場合、文字列は‘'
’のみでしか囲むことができず、サーバは識別子として‘"
’で囲まれた文字列を実行します。)
‘\
’は文字列内のエスケープ文字です。
SQLステートメントで、db_name.tbl_name
構文を使用して、さまざまなデータベース内のテーブルにアクセスできます。同様の機能備えたSQLサーバもありますが、これはUser
space
と呼ばれます。MySQLサーバでは、以下のステートメントで使用されるようなテーブルスペースはサポートされていません。CREATE
TABLE ralph.my_table ... IN my_tablespace
SQLステートメント構文
ANALYZE TABLE
、CHECK
TABLE
、OPTIMIZE
TABLE
そしてREPAIR
TABLE
ステートメント
CREATE DATABASE
、DROP
DATABASE
そしてALTER
DATABASE
ステートメント。項12.1.6. 「CREATE DATABASE
構文」、項12.1.12. 「DROP DATABASE
構文」、項12.1.1. 「ALTER DATABASE
構文」
などを参照してください。
DO
ステートメント
クエリオプティマイザによるテーブルの結合方法に関する説明を取得するEXPLAIN
SELECT
。
FLUSH
およびRESET
ステートメント
SET
ステートメント項12.5.3. 「SET
構文」
を参照してください。
SHOW
ステートメント詳しくは
項12.5.4. 「SHOW
構文」
を参照してください。MySQL
5.0以降では、MySQL特有のSHOW
ステートメントの多くから得られた情報は、INFORMATION_SCHEMA
クエリに対してSELECT
を使用することで、より標準化されます。章?21. INFORMATION_SCHEMA
データベース
を参照してください。
LOAD DATA
INFILE
の使用。多くの場合、この構文はOracleのLOAD
DATA
INFILE
と互換性があります。項12.2.5. 「LOAD DATA INFILE
構文」
を参照してください。
RENAME
TABLE
の使用。項12.1.19. 「RENAME TABLE
構文」
を参照してください。
DELETE
+INSERT
の代わりとしてのREPLACE
使用。項12.2.6. 「REPLACE
構文」
を参照してください。
ALTER
TABLE
ステートメントにおけるCHANGE
、col_name
DROP
、またはcol_name
DROP
INDEX
、IGNORE
またはRENAME
の使用。ALTER
TABLE
ステートメントにおける、複数ADD
、ALTER
、DROP
、またはCHANGE
節の使用。項12.1.2. 「ALTER TABLE
構文」
を参照してください。
インデックス名、カラムのプリフィックス上のインデックス、およびCREATE
TABLE
ステートメントでのINDEX
またはKEY
の使用。項12.1.8. 「CREATE TABLE
構文」
を参照してください。
CREATE
TABLE
を用いたTEMPORARY
またはIF
NOT EXISTS
の使用。
DROP TABLE
およびDROP
DATABASE
を用いたIF
EXISTS
の使用。
1つのDROP
TABLE
ステートメントで複数のテーブルを破棄することができます。
UPDATE
およびDELETE
ステートメントのORDER
BY
およびLIMIT
節。
INSERT INTO
構文。
tbl_name
SET
col_name
=
...
INSERT
およびREPLACE
ステートメントのDELAYED
節。
INSERT
、REPLACE
、DELETE
およびUPDATE
ステートメントのLOW_PRIORITY
節。
SELECT
ステートメントにおけるINTO
OUTFILE
またはINTO
DUMPFILE
の使用。項12.2.7. 「SELECT
構文」
を参照してください。
SELECT
ステートメントにおける、STRAIGHT_JOIN
もしくはSQL_SMALL_RESULT
のようなオプション。
GROUP
BY
節で、選択したすべてのカラムの名前を列挙する必要はありません。これにより、ごく一部ではありますが、きわめて一般的なクエリのパフォーマンスが向上します。項11.11. 「GROUP BY
句との関数および修飾子の使用」
を参照してください。
ORDER
BY
を用いるだけでなくGROUP
BY
を用いても、ASC
およびDESC
を指定できます。
:=
代入演算子を使用して、ステートメント内で変数を設定できます。
mysql>SELECT @a:=SUM(total),@b:=COUNT(*),@a/@b AS avg
->FROM test_table;
mysql>SELECT @t1:=(@t2:=1)+@t3:=4,@t1,@t2,@t3;
データ型
MEDIUMINT
、SET
およびENUM
データ型、そして様々なBLOB
およびTEXT
データ型。
AUTO_INCREMENT
、BINARY
、NULL
、UNSIGNED
そしてZEROFILL
データ型の属性。
関数と演算子
他の SQL 環境を使用していたユーザにわかりやすいように、MySQL サーバでは多数の関数のエイリアスがサポートされています。たとえば、すべての文字列関数で、標準の SQL 構文と ODBC 構文の両方がサポートされています。
MySQL サーバでは、C
プログラミング言語のように、||
および &&
演算子が論理 OR および AND
を意味すると解釈されます。 MySQL
サーバでは、||
と
OR
、および&&
と AND
はシノニムです。このすぐれた構文のために、MySQL
サーバでは、文字列の連結に標準 SQLの
||
演算子を使用することができません。その代わりに、CONCAT()
を使用します。CONCAT()
には引数をいくつでも使用できるので、||
演算子の使用を MySQL
サーバに変換するのは簡単です。
value_list
に1つ以上の要素がある場合の、COUNT(DISTINCT
の使用。
value_list
)
すべての文字列比較は、デフォルトでは大文字と小文字を区別せず、現在のキャラクタセット照合順序
で決められたソート順で行われます。このキャラクタセット照合順序は、デフォルトではlatin1
(cp1252
West
European)です。これを変更するには、BINARY
属性を指定してカラムを宣言するか、BINARY
キャストを使用して、字句順序よりもキャラクタコード値を使用して比較が行われるようにする必要があります。
%
演算子はMOD()
のシノニムです。したがって、
はN
%
M
MOD(
と同じです。N
,M
)%
は、C
プログラマを対象として、また PostgreSQL
との互換性を確保するためにサポートされています。
=
、<>
、<=
、<
、>=
、>
、<<
、>>
、<=>
、AND
、OR
、またはLIKE
演算子を、SELECT
ステートメントのFROM
の左側のカラム比較で使用することができます。例
:
mysql> SELECT col1=1 AND col2=2 FROM my_table;
LAST_INSERT_ID()
関数は、最新のAUTO_INCREMENT
値を返します。項11.10.3. 「情報関数」
を参照してください。
LIKE
は数値上で許可されます。
REGEXP
およびNOT
REGEXP
拡張正規表現演算子。
1
つまたは複数の引数を使用する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では、1つの文字しか削除できない。
GROUP
BY
関数STD()
、BIT_OR()
、BIT_AND()
、BIT_XOR()
、およびGROUP_CONCAT()
。項11.11. 「GROUP BY
句との関数および修飾子の使用」
を参照してください。
優先順位に従って並べられた、新しい拡張機能が MySQL サーバに追加される時期を示す一覧については、http://dev.mysql.com/doc/mysql/en/roadmap.htmlにあるオンラインのMySQL開発ロードマップを参照してください。
MySQL サーバを ANSI SQL 標準および ODBC SQL 標準に準拠したものにすることを目標としていますが、以下のように、MySQL サーバが異なる動作を示すことがあります。
VARCHAR
型のカラムでは、値が格納される際に後続のスペースが削除されます。(これは、MySQL
5.0.3で修復されています。)項B.1.8. 「Known Issues in MySQL」
を参照してください。
テーブルを定義した場合やその構成を変更した場合、CHAR
型のカラムが自動的に
VARCHAR
型のカラムに変更されることがあります。(これは、MySQL
5.0.3で修復されています。)
MySQLと標準SQLの権限システムには、いくつかの違いがあります。たとえばMySQLでは、テーブルを削除しても、テーブルの権限が自動的に取り消されません。テーブルの権限を取り消すには、明示的にREVOKE
を発行する必要があります。詳細は
項12.5.1.5. 「REVOKE
構文」 をご覧ください。
CAST()
関数は、REAL
またはBIGINT
に対するキャストをサポートしていません。項11.8. 「キャスト関数と演算子」
を参照してください。
標準SQLは、SELECT
ステートメント内のHAVING
節が、GROUP
BY
節のカラムを参照できるよう要求します。このことは、MySQL
5.0.2以前ではできません。
MySQL
4.1以降では、サブクエリと派生テーブルがサポートされています。「サブクエリ」は、他のステートメント内にネストされたSELECT
ステートメントです。「派生テーブル」
(名前のないビュー)は他のステートメントのFROM
節内のサブクエリです。項12.2.8. 「サブクエリ構文」
を参照してください。
4.1 より前のバージョンの MySQL については、結合などの方法によって、ほとんどのサブクエリを記述し直すことができます。詳しい方法例は、項12.2.8.11. 「MySQL 初期バージョンにおいて、サブクエリの接合としての書き換え」を参照してください。
MySQL サーバでは、Sybase SQL 拡張機能SELECT
... INTO
TABLE
はまだサポートされていません。代わりに、標準SQL構文INSERT
INTO ...
SELECT
がサポートされています。これらは、基本的には同じです。詳しくは
項12.2.4.1. 「INSERT ... SELECT
構文」
を参照してください。例 :
INSERT INTO tbl_temp2 (fld_id) SELECT tbl_temp1.fld_order_id FROM tbl_temp1 WHERE tbl_temp1.fld_order_id > 100;
また、SELECT ... INTO
OUTFILE
またはCREATE TABLE ...
SELECT
を使用することもできます。
MySQL
5.0以降では、ユーザによって定義された変数でSELECT
...
INTO
を使用することができます。同じ構文も、カーソルとローカル変数を用いてストアドルーチン内で使用できます。項17.2.7.3. 「SELECT ... INTO
ステートメント」
を参照してください。
MySQL サーバ(バージョン 3.23-max
およびすべてのバージョン 4.0
以降)では、InnoDB
トランザクションストレージエンジンでトランザクションがサポートされています。InnoDB
は完全に
ACID
に準拠しています。詳しくは
章?13. ストレージエンジンとテーブルタイプ
を参照してください。トランザクションエラーの取り扱いにおける、標準SQLとInnoDB
との違いについては項13.5.15. 「InnoDB
エラー処理」を参照してください。
MySQL
サーバのその他の非トランザクションストレージエンジン(MyISAM
など)は、「アトミックオペレーション」と呼ばれる別のデータ整合性のパラダイムに従います。トランザクションの観点では、MyISAM
テーブルは事実上、常に
AUTOCOMMIT=1
モードで動作すると言えます。アトミックオペレーションでは多くの場合、パフォーマンスの高さに値する整合性が確保されます。
両方のパラダイムをサポートする MySQL サーバでは、ユーザはアトミックオペレーションの速度を必要とするか、アプリケーションでトランザクション機能を使用する必要があるかを選択することができます。この選択は、テーブルごとに行うことができます。
ほとんどの場合、トランザクションストレージエンジンと非トランザクションストレージエンジンのどちらを選ぶかの決め手となるのはパフォーマンスです。トランザクションテーブルの場合、はるかに大きなメモリとディスク領域が必要で、CPU
のオーバーヘッドも大きくなります。しかし、InnoDB
のようなトランザクションストレージエンジンには特有の機能も多数あります。MySQLサーバのモジュール設計によって、このようなさまざまなストレージエンジンすべてを同時に使用することができるので、さまざまな要件に合わせて、あらゆる条件で最適なパフォーマンスを確保することが可能です。
しかし、MySQL
サーバの機能を使用して、非トランザクションの
MyISAM
テーブルでも厳密な整合性を確保するにはどのようにすればよいのでしょうか。また、非トランザクションテーブルの機能はトランザクションストレージエンジンにどのように対抗できるのでしょうか。
トランザクションパラダイムでは、重大な状況で
COMMIT
ではなく
ROLLBACK
の呼び出しに依存するようにアプリケーションが作成されている場合、トランザクションの方が便利です。また、トランザクションでは、完了していない更新や失敗した活動がデータベースにコミットされることはない。サーバには自動ロールバックを行う機会が与えられ、データベースは保護されます。
非トランザクションテーブルを使用している場合、MySQL サーバでは、ほとんどの場合、更新前に簡単なチェックを組み込んだり、データベースの不整合をチェックして、不整合が発生した場合には自動的に修復または警告する簡単なスクリプトを実行したりすることで、発生する可能性がある問題を解決することができます。MySQL ログを使用したり、別のログを 1 つ追加したりするだけで、通常、データの整合性が失われることなく、完全にテーブルを修復することができます。
ほとんどの場合、重要なトランザクション更新はアトミックな更新に記述し直すことができます。通常、トランザクションによって解決される整合性の問題はすべて、LOCK
TABLES
またはアトミックな更新を使用して解決することができます。これによって、サーバが自動的に停止するという、トランザクションデータベースシステムと共通する問題が回避されます。
MySQL サーバを安全に使用するには、トランザクションテーブルを使用するかどうかに関係なく、バックアップを作成し、バイナリログをオンにするだけです。これにより、他のトランザクションデータベースシステムで可能なように、どのような状況からもリカバリすることができます。使用するデータベースシステムに関係なく、どのような場合でもバックアップを作成することが望ましいのは当然です。
トランザクションパラダイムには長所と短所があります。多数のユーザおよびアプリケーション開発者は、停止が発生する、または停止が必要な問題に関するコード化の容易さに頼っています。しかし、アトミックオペレーションのパラダイムに慣れていなかったり、トランザクションの方が詳しいという場合でも、非トランザクションテーブルの速度が、最も高速で最適に調整されたトランザクションテーブルの速度の 3 倍から 5 倍も速いという長所を考えてみてください。
整合性が最も重要な状況では、MySQL
サーバは、非トランザクションテーブルでもトランザクションレベルの信頼性と整合性を提供します。LOCK
TABLES
を使用してテーブルをロックすると、整合性チェックが行われるまで、すべての更新が延期されます。テーブルエンドで同時挿入が可能なREAD
LOCAL
ロック(書き込みロックの逆)が設定されている場合、他のクライアントによる読み取りと挿入は引き続き行うことができます。新しく挿入したレコードは、読み取りがロックされているクライアントには、読み取りロックが解除されるまで表示されません。INSERT
DELAYED
を使用すると、ロックが解除されるまで挿入をローカルキューに入れることができ、クライアントは挿入が完了するまで待機する必要はありません。項6.3.3. 「同時挿入」
および 項12.2.4.2. 「INSERT DELAYED
構文」
を参照してください。
ここでいう「アトミック」とは、魔法のようなものではありません。個々の更新の実行中は、他のユーザがそれを妨害できないようにするとともに、自動ロールバック(あまり注意を払わなかった場合に、トランザクションテーブルで行われることがあります)が行われないようにすることができるというだけです。また、MySQL サーバでは、ダーティリードが行われることもありません。
非トランザクションテーブルを使用する際のテクニックは、以下のとおりです。
LOCK
TABLES
を使用して、通常はトランザクションを必要とするループをコード化することができる。そのため、実行中にレコードを更新するカーソルが不要です。
ROLLBACK
を使用しないように、以下の方法を使用することができます。
LOCK TABLES
を使用して、アクセスするすべてのテーブルをロックします。
更新する前に条件をテストします。
すべてに問題がなければ、更新します。
UNLOCK
TABLES
を使用して、ロックを解除します。
常にではありませんが、これは通常ロールバックが行われる可能性があるトランザクションを使用するよりも、はるかに速い方法です。ただし、更新の途中でスレッドが停止された場合は、この方法では対応することができません。その場合、すべてのロックが解除されるが、一部の更新が実行されていない可能性があります。
関数を使用して、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_owed_to_us=money_owed_to_us-125 WHERE customer_id=id AND address='old address' AND phone='old phone';
これは非常に効率的で、別のクライアントがpay_back
または
money_owed_to_us
カラムの値を変更していても動作します。
多くの場合、ユーザは、複数のテーブルの一意の識別子を管理するために
LOCK TABLES
や
ROLLBACK
を使用していました。これは、AUTO_INCREMENT
カラムおよびSQL関数LAST_INSERT_ID()
またはC
API関数mysql_insert_id()
を使用することで、ロックやロールバックをせずにはるかに効率的に処理することができます。項11.10.3. 「情報関数」
および 項23.2.3.37. 「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;
ストアドプロシージャと関数は、MySQL 5.0から実装されます。章?17. ストアドプロシージャとファンクション を参照してください。
基本的なトリガの機能はMySQL 5.0.2から実装されており、MySQL 5.1に向けて更なる開発が計画されています。.章?18. トリガ を参照してください。
MySQL サーバ 3.23.44
以降では、CASCADE
、ON
DELETE
、および ON UPDATE
を含む外部キー制約のチェックが
InnoDB
ストレージエンジンでサポートされています。.項13.5.6.4. 「FOREIGN KEY
制約」
を参照してください。
InnoDB
以外のストレージエンジンについては、MySQL
サーバでは現在、CREATE TABLE
ステートメントで FOREIGN
KEY
構文のみが解析されますが、この情報は使用/保存されません。近いうちに、この情報がテーブル仕様ファイルに保存され、mysqldump
および ODBC
によって取得できるように、この実装を拡張する予定です。さらにその後には、MyISAM
テーブルについても外部キー制約を実装する予定です。
データベース開発者にとって、外部キーを使用するメリットは以下のとおりです。
関係が適切に設計されている場合、外部キー制約によって、プログラマがデータベースで不整合を引き起こすことが少なくなります。
データベースサーバによって集中的に制約チェックが行われるため、アプリケーション側でのこれらのチェックが不要になります。同様にこのことで、各アプリケーションで制約がすべてチェックされないといった可能性がなくなります。
連鎖更新および削除を使用すると、アプリケーションコードを単純化することができます。
適切に設計された外部キールールは、テーブル間の関係の記述に役立ちます。
これらのメリットには、必要なチェックを行なうため、データベースサーバの追加オーバーヘッドという犠牲が付随することに留意してください。サーバでの余分なチェックによってパフォーマンスに影響が生じるため、一部のアプリケーションでは、可能であればこれを避けるよう設定されています。(このため、主要な商用アプリケーションの中には、アプリケーションレベルでこの外部キーロジックがコード化されているものもあります。)
MySQLでは、データベース開発者が使用するアプローチを選択できます。外部キーが不必要で、かつ参照整合性をチェックすることで生じるオーバーヘッドを避ける必要がなければ、MyISAM
のような他のストレージエンジンを代わりに選択できます。(たとえば、MyISAM
ストレージエンジンでは、INSERT
やSELECT
オペレーションでのみ行なわれるアプリケーションのパフォーマンスが、非常に高速に行なわれるようになります。この場合、テーブルの中間に欠如はなく、挿入は検索と同時に行なわれます。項6.3.3. 「同時挿入」
参照。)
参照整合性チェックを利用しない場合は、次のことに留意してください。
サーバ側の外部キー関係チェックを使用しない場合、アプリケーション自身で関係についての問題を処理しなければなりません。たとえば、適切な順序でテーブルに行を挿入し、分断段落レコードの作成を避けるように注意してください。複合レコード挿入オペレーションの中間で生じるエラーから回復することも可能です。
ON
DELETE
が、アプリケーションが必要とする参照整合性能力のみの場合、1つのステートメントで多くのテーブルから行を削除するために、複数テーブルのDELETE
ステートメントを使用してMySQL4.0サーバと同様の結果を得ることができます。項12.2.1. 「DELETE
構文」
を参照してください。
ON
DELETE
が実装されていないという問題に対処するには、外部キーがあるテーブルからレコードを削除する際に適切なDELETE
ステートメントをアプリケーションに追加します。実際、この方法は外部キーを使用する場合と同じくらい簡単で、移植性はそれよりもはるかに高くなります。
外部キーを使用するデメリットは以下のとおりです。
外部キーサポートは多くの参照性合成問題をアドレス指定しますが、キー関係を設計する上で犯しやすい間違いによって、循環ルール、連鎖削除の不適切な組み合わせなどの深刻な問題が生じることがあります。
DBA
にとって、個々のテーブルのバックアップやリストアが非常に困難になり、場合によっては不可能になるような複雑な関係のトポロジを作成することはめったにありません。(MySQLは、他のテーブルに依存するテーブルをリロードする際、一時的に外部キーチェックを使用できないようにすることで、この問題を軽減します。詳しくは
項13.5.6.4. 「FOREIGN KEY
制約」
を参照してください。MySQL
4.1.1以降では、mysqldumpは、リロードの際に自動的にこの能力を利用するダンプファイルを生成します。)
SQLの外部キーは、テーブルを結合させずに参照整合性をチェックおよび実行します。SELECT
ステートメントで複数テーブルからの結果を得たい場合は、以下のようにjoinを行なってください。
SELECT * FROM t1 INNER JOIN t2 ON t1.id = t2.id;
項12.2.7.1. 「JOIN
構文」およびUsing Foreign Keysを参照してください。
ON DELETE
...
を使用しないFOREIGN
KEY
構文は、自動的にWHERE
節を作成するために、ODBCアプリケーションで使用されることが多々あります。
(更新可能なビューを含む)ビューは、MySQLサーバ5.0.1から実装されます。章?20. ビューを参照してください。
ビューは、1 つのテーブルのように一連の関係(テーブル)にユーザがアクセスできるようにし、ユーザのアクセスをそれのみに制限する場合に便利です。また、ビューを使用して、行(特定のテーブルのサブセット)へのアクセスを制限することもできます。MySQL サーバには高度な権限システムがあるので、カラムへのアクセスを制限する場合にはビューを使用する必要はありません。項4.7. 「MySQL アクセス権限システム」 を参照してください。
当社はビューの実装を設計する際に、リレーショナルデータベースシステムに関する 「コッドのルール#6」 に、 SQL の範囲内で可能な限り準拠することを目標としています。「これは、理論的に更新可能なすべてのビューは実際にも更新可能でなければならないというものです。」
標準SQLでは、コメントにC構文/* this is a
comment
*/
が使用され、MySQLサーバでも同様にこの構文がサポートされています。MySQLでもまた、項8.5. 「コメント構文」で記述されているように、MySQL固有のSQLをコメントに組み込ませる構文に対する拡張子がサポートされています。
標準SQLでは、コメント開始
シーケンスとして‘--
’が使用されます。MySQLサーバでは、コメント開始文字として‘#
’が使用されます。MySQLサーババージョン
3.23.3
以降でも、‘--
’コメントスタイルを使用することができます。ただし、‘--
’コメント開始シーケンスは、後にスペース(または、改行などの制御文字)が続かなければなりません。これは、このコメントスタイルによって、payment
の値を自動的に挿入する次のようなコードを使用した自動生成の
SQL
クエリで多数の問題が発生していたためです。
UPDATE account SET credit=credit-payment
payment
の値が負数(-1
など)の場合、どうなるかを考えてみてください。
UPDATE account SET credit=credit--1
SQLではcredit--1
は有効表現ですが、‘--
’はコメント開始の一部として解釈され、表現の一部が破棄されてしまいます。結果として、意図したものとはまったく異なる意味を持つステートメントとなってしまいます。
UPDATE account SET credit=credit
ステートメントでは、値が変更されることは一切ありません。このことは、コメントが‘--
’で開始する場合に、重大な影響があることを示しています。
MySQLサーバ3.23.3以降でこの方法の実装を使用する場合、コメント開始シーケンスとして認識されるように、‘--
’の後にスペースが続かなければなりません。したがって、credit--1
は安全に使用できます。
もう 1
つの安全な機能は、mysqlコマンドラインクライアントによって
‘--
’で始まるすべての行が削除されるというものです。
以下の情報は、3.23.3 より前のバージョンの MySQL を実行している場合にのみ関連します。
テキストファイルの SQL
スクリプトに‘--
’コメントが含まれている場合、スクリプトを実行する前に、‘#
’文字を使用するためのコメントを以下のように変換するreplace機能を使用する必要があります。
shell>replace " --" " #" < text-file-with-funny-comments.sql \
| mysql
db_name
これは通常の方法でスクリプトを実行するよりも安全です。
shell> mysql db_name
< text-file-with-funny-comments.sql
また、スクリプトファイルを
「その場で」編集して、‘--
’コメントを
‘#
’
コメントに変更することもできます。
shell> replace " --" " #" -- text-file-with-funny-comments.sql
次のコマンドで元に戻してください。
shell> replace " #" " --" -- text-file-with-funny-comments.sql
項7.19. 「replace ? 文字列置き換えユーティリティ」 を参照してください。
MySQL ではトランザクションテーブルとロールバックが有効でない非トランザクションテーブルの両方を使用することができます。このため、MySQL と他のデータベースとでは制約の処理が多少異なります。エラー時にロールバックすることができない非トランザクションテーブルで、多数の行を更新または挿入した場合の処理を実装しなければなりません。
基本的な概念は、MySQLサーバが検出可能なエラーをコンパイル時に生成し、受け取ったエラーから実行時にリカバリするというものですほとんどの場合にこれが実装されていますが、まだすべてについて実装されているわけではありません。
MySQL における基本的なオプションは、途中でステートメントを中止するか、問題からリカバリするためにできる限りのことを行って、処理を続行するかです。デフォルトでは、サーバは後者の方法に従います。たとえば、サーバは無効値を、近い値を持つ有効値に強制変換する可能性があります。
いくつかのSQLモードオプションでは、不良データ値の処理やエラー時にステートメント実行が継続されるか中止されるかといった処理がコントロールできます。これらのオプションを使用して、他のデータベースが不適切な入力を拒絶するのと同じように、MySQLサーバをより従来に近い方法で働くようにコンフィギュレーションを行なえます。SQLモードがサーバ起動時に広域で設定されることで、すべてのクライアントに影響を与えることができます。ランタイムに各クライアントがSQLモードを設定できることで、要求に最も適した起動状態が選択できるようになります。項4.2.6. 「SQL モード」 を参照してください。
さまざまな種類の制約に関する、MySQLサーバの処理方法を以下で説明します。
通常、主キー、ユニークキー、または外部キー違反を引き起こす行のINSERT
/UPDATE
を行おうとすると、エラーが発生します。InnoDB
のようなトランザクションストレージエンジンを使用している場合、MySQL
ではステートメントが自動的にロールバックされます。非トランザクションストレージエンジンを使用している場合、MySQL
はエラーが発生した行で停止し、残りの行は未処理のままになります。
このキー違反を無視する場合、MySQLではINSERT
やUPDATE
に対するIGNORE
キーワードが使用できます。この場合、キー違反は無視され、引き続き次の行が処理されます。項12.2.4. 「INSERT
構文」
および 項12.2.10. 「UPDATE
構文」
を参照してください。
mysql_info()
C
API関数で、実際に挿入/更新される行数についての情報が取得できます。MySQL
4.1以降では、SHOW
WARNINGS
ステートメントも利用可能です。項23.2.3.35. 「mysql_info()
」
および 項12.5.4.31. 「SHOW WARNINGS
構文」
を参照してください。
現時点では、外部キーがサポートされているのはInnoDB
テーブルのみです。詳しくは
項13.5.6.4. 「FOREIGN KEY
制約」
を参照してください。MyISAM
テーブルでの外部キーサポートは、MySQL
5.2で実装される予定です。項1.5. 「MySQL の開発ロードマップ」
を参照してください。
MySQLでは、デフォルトで無効や不適切なデータ値が許可されており、データ入力の際にそれらを有効値に強制変換します。しかし、サーバSQLモードを変更することで、不良値が生じた際にサーバが拒絶やステートメントの実行を中止するような、従来により近い不良値の処理方法が選択できます。項4.2.6. 「SQL モード」 を参照してください。
このセクションでは、MySQLのデフォルト(許可されている)処理方法と厳格SQLモードの処理方法の相違点について説明しています。
厳格モードを使用していない場合、NOT
NULL
カラムにおけるNULL
や数値カラムにおける大きすぎる数値のように「正しくない」
値をカラムに挿入すると、MySQL
ではエラーを生成するのではなく、カラムを「最適可能値」に設定します。この動作規則について、以下に詳しく説明します。
数値カラムに範囲外の値を格納しようとすると、代わりにMySQLサーバは0、使用可能な最小値、または使用可能な最大値(いずれも無効値に近い値)を 格納します。
文字列については、MySQLは空白文字列、またはカラム内で格納可能な最長文字列を格納します。
数値カラムに数値で始まらない文字列を格納しようとすると、MySQLサーバは0を格納します。
ENUM
やSET
カラムに対する無効値は、項1.8.6.3. 「ENUM
およびSET
制約」に記載のとおりに処理されます。
MySQLでは、DATE
やDATETIME
カラム('2000-02-31'
や'2000-02-00'
のようなもの)に、特定の不正確なデータ値を格納することが許可されています。これは、SQLサーバはデータ検証を行なわないことを意味します。データ値が格納できるか、または正確に同値が検索できる場合、MySQLはそれを既存値として格納します。日付が完全に不正確(サーバの格納能力を超えている)の場合は、代わりに特定の「ゼロ」日付値'0000-00-00'
がカラムに格納されます。
NULL
値を使用することができないカラムにNULL
を格納しようとすると、単一行INSERT
ステートメントに対するエラーが生じます。複数行INSERT
ステートメントやINSERT
INTO ...
SELECT
ステートメントに対して、MySQLサーバは、カラムデータ型に含まれるデフォルト値を格納します。たいていこれは、数値型の0
、文字列型の空白文字列(''
)、および日時型の「ゼロ」値です。暗黙のデフォルト値に関しては
項10.1.4. 「データタイプデフォルト値」
で説明されています。
INSERT
ステートメントがカラムに対して値を指定しない場合、MySQLはカラム定義が既存のDEFAULT
節を含んでいれば、そのデフォルト値を挿入します。定義にDEFAULT
節のような節が含まれていなければ、MySQLはカラムデータ型に含まれるデフォルト値を挿入します。
非厳格モードにおける前述のルールの理由は、ステートメントの実行が開始される前にこれらの条件をチェックできないためです。複数の行を更新した後で問題が発生した場合、ストレージエンジンでサポートされていない可能性があるため、単にロールバックすることはできません。停止するというオプションは、この場合、更新が「未完了」のため、最悪のシナリオになる可能性があるので、適切ではありません。この場合「できる限りのことを行って」、何も問題が発生していないものとして処理を続行する方が適切です。
MySQL
5.0.2以降では、STRICT_TRANS_TABLES
やSTRICT_ALL_TABLES
SQLモードを使用して、より厳格な入力値処理を行なうことができます。
SET sql_mode = 'STRICT_TRANS_TABLES'; SET sql_mode = 'STRICT_ALL_TABLES';
STRICT_TRANS_TABLES
では、トランザクショナルストレージエンジンに対して厳格モードが動作可能となり、同様に非トランザクショナルエンジンに対してもいくらかの拡張が可能となります。これは、以下のように動作します。
トランザクショナルストレージエンジンにとって、ステートメント内で生じる不良データ値は、ステートメントの実行中止やロールバックを引き起こします。
非トランザクショナルストレージエンジンにとって、挿入や更新がなされる最初の行でエラーが生じると、ステートメントの実行は中止されます。(トランザクショナルテーブルについては、最初の行でエラーが生じた場合、テーブルを変換させないようにするためにステートメントの実行を中止することができます。)2行以降でエラーが生じた場合は、ステートメント実行は中止されません。これは、最初の行によってテーブルが既に変換されているためです。.エラー発生の代わりに不良データ値が適応され、この結果警告が発せられます。言い換えると、テーブルが変換されない場合は、STRICT_TRANS_TABLES
によって、不正確な値はMySQLにそれまでに行なわれたすべての更新をロールバックさせます。しかし、いったんテーブルが変換されると、それ以降に生じるエラーは適応や警告になります。
STRICT_ALL_TABLES
は、より厳格なチェックについても使用できます。.非トランザクショナルストレージエンジンでは2行以降の不良値に対してもエラーがステートメント実行を中止する、という点を除くと、上記のことはSTRICT_TRANS_TABLES
と同じです。これは、非トランザクショナルテーブルへの複数行挿入もしくは更新の途中でエラーが生じた場合、部分的な更新のみが行なわれるということを意味します。より前の行が挿入または更新されますが、それらはエラーから生じるものではありません。非トランザクショナルテーブルでこのことを避けるには、エラーよりも変換警告のほうが適切な場合、単一行ステートメントまたはSTRICT_TRANS_TABLES
のどちらかを使用してください。初期段階でこのような問題を避けるには、MySQLでカラム内容をチェックさせないようにしてください。データベースに対して確実に有効値のみが通過するようにアプリケーションを設定することが、最も安全(であり、時には高速)な方法です。
厳格モードオプションのいずれかで、IGNORE
を用いずにINSERT
やUPDATE
よりも、INSERT
IGNORE
またはUPDATE
IGNORE
を用いることで、エラーを警告として処理することができます。
ENUM
およびSET
カラムによって、特定の値セットのみを含むカラムを効率的に定義することができます。項10.4.4. 「ENUM
タイプ」
と 項10.4.5. 「SET
タイプ」
を参照してください。ただし、MySQL
5.0.2以前では、ENUM
およびSET
カラムは無効値の入力に対する実際の制約ではありません。
ENUM
カラムには常にデフォルト値があります。デフォルトでない値を指定した場合、それはNULL
を持ちうるカラムに対するNULL
となります。もしくは、
カラム定義における最初の列挙値となります。
ENUM
カラムに正しくない値を挿入した場合、もしくはIGNORE
を用いてENUM
カラムにある値を強制した場合は、予約された列挙値0
に設定され、文字列コンテキストでは空白文字列として表示されます。
SET
カラムに正しくない値を挿入した場合、その値は無視されます。たとえば、カラムが'a'
、'b'
、そして'c'
値を含む場合、'a,x,b,y'
を割り当てようとすると'a,b'
値になってしまいます。
MySQL
5.0.2以降では、厳格SQLモードを使用するためにサーバのコンフィギュレーションを行なうことができます。詳しくは
項4.2.6. 「SQL モード」
を参照してください。厳格モードを使用している場合、ENUM
やSET
カラムの定義は、カラム入力値の制約としては振舞いません。これらの条件を満たさない値に対しては、エラーが生じます。
ENUM
値はカラム定義に一覧表示されているものか、もしくはそれについて同等の内部数値でなければなりません。その値はエラー値(つまり、0または空白文字列)にはなりえません。ENUM('a','b','c')
として定義されるカラムに対して、''
、'd'
または'ax'
といった値は無効であり、かつ拒絶されます。
SET
値は空白文字列、もしくはコンマで区切られたカラム定義に挙げられている値のみで構成された値でなければなりません。SET('a','b','c')
として定義されるカラムにとって、'd'
または'a,b,c,d'
といった値は無効であり、かつ拒絶されます。
無効値に対するエラーは、INSERT
IGNORE
やUPDATE
IGNORE
を使用している場合、厳格モードで抑制されます。この場合、エラーではなく警告が発せられます。ENUM
に対しては、その値はエラーメンバー(0
)として挿入されます。SET
に対しては、どの無効部分文字列も消去されるという点を除いて、その値は既存のものとして挿入されます。たとえば、'a,x,b,y'
は'a,b'
値となります。