第 1 章 一般情報

目次

1.1 このマニュアルについて
1.2 表記規則および構文規則
1.3 MySQL データベース管理システムの概要
1.3.1 MySQL とは
1.3.2 MySQL の主な機能
1.3.3 MySQL の歴史
1.4 MySQL 5.6 の新機能
1.5 MySQL の情報源
1.5.1 MySQL メーリングリスト
1.5.2 MySQL フォーラムにおける MySQL コミュニティーサポート
1.5.3 IRC (インターネットリレーチャット) の MySQL コミュニティーサポート
1.5.4 MySQL Enterprise
1.6 質問またはバグをレポートする方法
1.7 MySQL の標準への準拠
1.7.1 標準 SQL に対する MySQL 拡張機能
1.7.2 MySQL と標準 SQL との違い
1.7.3 MySQL における制約の処理
1.8 クレジット
1.8.1 MySQL への貢献者
1.8.2 ドキュメント作成者および翻訳者
1.8.3 MySQL をサポートするパッケージ
1.8.4 MySQL の作成に使用されたツール
1.8.5 MySQL のサポータ

MySQL™ ソフトウェアは、マルチスレッドおよびマルチユーザー対応の非常に高速で堅固な SQL (構造化クエリー言語) データベースサーバーを提供します。MySQL Server は、ミッションクリティカルで負荷が高い運用システムにも、大規模に配備されるソフトウェアへの組み込みにも対応するように設計されています。Oracle は Oracle Corporation およびその関連企業の登録商標です。MySQL は Oracle Corporation およびその関連企業の商標であり、Oracle による書面による明示的な認可なしに使用できません。その他の名称は、それぞれの所有者の商標です。

MySQL ソフトウェアはデュアルライセンス製品です。ユーザーは、GNU General Public License (http://www.fsf.org/licenses/) の条件で、MySQL ソフトウェアをオープンソース製品として使用するか、Oracle からの標準的な商用ライセンスを購入するかを選択できます。ライセンスポリシーの詳細は、http://www.mysql.com/company/legal/licensing/を参照してください。

このマニュアルで特に興味深いセクションは次のとおりです。

重要

問題またはバグをレポートするには、セクション1.6「質問またはバグをレポートする方法」で説明する手順を使用してください。MySQL Server で慎重に扱うべきセキュリティー上のバグを発見した場合は、ただちに に電子メールメッセージを送信してお知らせください。例外: サポートのお客様は、セキュリティーのバグを含むすべての問題を Oracle Support までレポートしてください。

1.1 このマニュアルについて

これは、MySQL Database System バージョン 5.6 (リリース 5.6.23 まで) のリファレンスマニュアルです。MySQL 5.6 のマイナーバージョン間での相違点は、リリース番号 (5.6.x) に関連した現在のテキストに記されます。ライセンス情報については、法的通知を参照してください。この製品には、サードパーティーのコードが含まれる場合があります。サードパーティーコードのライセンス情報については、付録E「サードパーティーコンポーネントライセンスを参照してください。

MySQL 5.6 と以前のバージョンとの間に機能などの多くの相違点があるため、このマニュアルは MySQL ソフトウェアの古いバージョンで用することは想定されていません。MySQL ソフトウェアの以前のリリースを使用している場合は、該当するマニュアルを参照してください。たとえば、MySQL 5.5 リファレンスマニュアルには、5.5 シリーズの MySQL ソフトウェアリリースが取り上げられています。

これはリファレンスマニュアルであるため、SQL やリレーショナルデータベースの概念に関する一般的な説明は記載していません。また、使用しているオペレーティングシステムやコマンド行インタープリタの使用法も記載していません。

MySQL データベースソフトウェアは継続して開発が行われているため、リファレンスマニュアルも頻繁に更新されます。マニュアルの最新版は、オンラインで https://dev.mysql.com/doc/ の検索可能なフォームから入手できます。ここでは、HTML、PDF、EPUB バージョンなどのその他の形式も入手できます。

リファレンスマニュアルのソースファイルは、DocBook XML 形式で記述されています。HTML バージョンとその他の形式は、主に DocBook XSL スタイルシートを使用して自動的に作成されます。DocBook の詳細は、http://docbook.org/を参照してください。

MySQL を利用するにあたって質問がある場合は、メーリングリストやフォーラムを使用してお尋ねください。セクション1.5.1「MySQL メーリングリスト」およびセクション1.5.2「MySQL フォーラムにおける MySQL コミュニティーサポート」を参照してください。マニュアル自体に対する追加または修正に関する提案がある場合は、http://www.mysql.com/company/contact/ に送信してください。

このマニュアルは当初、David Axmark と Michael Monty Widenius によって執筆されました。Paul DuBois、Edward Gilmore、Stefan Hinz、David Moss、Philip Olson、Daniel Price、Daniel So、および Jon Stephens から構成される MySQL ドキュメントチームによって維持されています。

1.2 表記規則および構文規則

このマニュアルは、次の表記規則に従って記載されています。

  • このスタイルのテキストは、SQL ステートメント、データベース、テーブル、カラム名、プログラムリスト、ソースコード、環境変数に使用されます。例: 付与テーブルをリロードするには、FLUSH PRIVILEGES ステートメントを使用します。

  • このスタイルのテキストは、例の中で入力する文字の例を示します。

  • このスタイルのテキストは、mysql (MySQL コマンド行のクライアントプログラム) および mysqld (MySQL Server 実行可能ファイル) である実行可能プログラムおよびスクリプトの名前を示します。

  • このスタイルのテキストは、独自に選択する値に置き換える変数入力に使用されます。

  • このスタイルのテキストは、強調に使用されます。

  • このスタイルのテキストは、表の見出しや特に重要なことを示すときに使用されます。

  • このスタイルのテキストは、プログラムの実行方法に影響を与えるか、またはプログラムが特定の方法で機能するために必要な情報を提供するプログラムオプションを示すために使用されます。: --host オプション (短縮形 -h) は、mysql クライアントプログラムに対して接続すべき MySQL Server のホスト名または IP アドレスを指示します

  • ファイル名とディレクトリ名は次のように表示されます。グローバル my.cnf ファイルは、/etc ディレクトリにあります。

  • 文字シーケンスは次のように表示されます。ワイルドカードを指定するには、% 文字を使用します。

特定のプログラム内から実行されるコマンドが示される場合、そのコマンドの前に記されるプロンプトは、どのコマンドが使用されるかを示しています。たとえば、shell> はログインシェルから実行するコマンドを示し、root-shell> は同様ですが root として実行する必要があり、mysql>mysql クライアントプログラムから実行するステートメントを示します。

shell> type a shell command hereroot-shell> type a shell command as root heremysql> type a mysql statement here

領域によっては、コマンドを 2 つの異なる環境で実行すべきであることを示すために、異なるシステムが区別される場合があります。たとえば、レプリケーションを操作する場合、コマンドの前に master および slave が記される場合があります。

master> type a mysql command on the replication master hereslave> type a mysql command on the replication slave here

shell は、コマンドインタープリタです。UNIX の場合、これは通常、shcshbash などのプログラムです。Windows の場合、同等のプログラムは command.com または cmd.exe で、通常コンソールウィンドウで実行します。

例に示されるコマンドまたはステートメントを入力する場合、その例に示されるプロンプトを入力する必要はありません。

データベース名、テーブル名、およびカラム名は多くの場合、ステートメントに代入する必要があります。このような代入が必要であることを示す場合、このマニュアルでは db_nametbl_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

構文要素が複数の選択肢で構成される場合、選択肢は縦棒 (|) で区切られます。一連の選択肢から 1 つのメンバーを選択できる場合、選択肢は角かっこ ([ および ]) 内にリストされます。

TRIM([[BOTH | LEADING | TRAILING] [remstr] FROM] str)

一連の選択肢から 1 つのメンバーを選択しなければならない場合、選択肢は中かっこ ({ および }) 内にリストされます。

{DESCRIBE | DESC} tbl_name [col_name | wild]

省略記号 (...) は、ステートメントの一部が省略されていることを示し、通常、複雑な構文を簡単に記しています。たとえば、SELECT ... INTO OUTFILE は、ステートメントのほかの部分に INTO OUTFILE 句が続く SELECT ステートメントを省略したものです。

省略記号は、ステートメントで前にある構文要素を繰り返すことができる場合にも使用されます。次の例では、reset_option 値を、最初のもの以外はそれぞれカンマを前に付けて、複数回繰り返すことができます。

RESET reset_option [,reset_option] ...

シェル変数を設定するコマンドは、Bourne シェル構文を使用して示されます。たとえば、CC 環境変数を設定し、configure コマンドを実行するシーケンスは、Bourne シェル構文では次のように示されます。

shell> CC=gcc ./configure

csh または tcsh を使用する場合、多少異なるコマンドを入力する必要があります。

shell> setenv CC gccshell> ./configure

1.3 MySQL データベース管理システムの概要

1.3.1 MySQL とは

MySQL は、もっとも普及しているオープンソース SQL データベース管理システムで、オラクル社により開発、流通、およびサポートが行われています。

MySQL ウェブサイト (http://www-jp.mysql.com/) では、MySQL ソフトウェアに関する最新情報を提供しています。

  • MySQL はデータベース管理システムです。

    データベースとは、構造化されたデータの集合です。簡単なショッピングリストから絵画のギャラリー、または社内ネットワークの膨大な量の情報など、さまざまなものがあります。コンピュータデータベースに格納されているデータに対して追加、アクセス、および処理などを行うには、MySQL Server のようなデータベース管理システムが必要となります。コンピュータは大量のデータの処理に非常に優れているので、データベース管理システムは、スタンドアロンのユーティリティーまたはほかのアプリケーションの一部として、データ処理の中心的な役割を果たします。

  • MySQL データベースはリレーショナルデータベースです。

    リレーショナルデータベースは、すべてのデータを 1 つの大きな保管場所に置くのではなく、独立したテーブルに保存します。データベースの構造は、速度を最適化した物理ファイルにわかれています。データベース、テーブル、ビュー、行、およびカラムなどのオブジェクトをもつ論理モデルは、柔軟なプログラミング環境を提供します。さまざまなデータフィールドの間の関係を統治する、1 対 1、1 対多、一意、必須またはオプションなどのルールと、さまざまなテーブル間のポインタを設定します。適切に設計されたデータベースを使用すれば、アプリケーションにはデータの矛盾、重複、孤立、期限切れ、または欠損が決して現れないように、データベースはこれらのルールを実施します。

    MySQL の、SQL の部分は Structured Query Language (構造化クエリー言語) を表しています。SQL は、データベースにアクセスするために使用されるもっとも一般的な標準化言語です。プログラミング環境によって、SQL を直接入力 (たとえばレポートの作成)、別の言語で作成されたコードに SQL ステートメントを埋め込み、または SQL 構文を隠す言語固有の API を使用する場合があります。

    SQL は ANSI/ISO SQL 標準で定義されます。SQL 標準は 1986 年以降開発が繰り返され、複数のバージョンがあります。本マニュアルでは、SQL-92 は 1992 年にリリースされた標準に、SQL:1999 は 1999 年にリリースされた標準に、そして SQL:2003 は標準の現バージョンに対応しています。SQL 標準 という用語は、任意の時点における現行バージョンの SQL 標準を表す場合に使用します。

  • MySQL ソフトウェアはオープンソースです。

    オープンソースとは、そのソフトウェアをだれでも使用および修正できることを意味します。MySQL ソフトウェアは、だれもが無料でインターネットからダウンロードし、使用することができます。必要に応じて、ソースコードを調べ、ニーズに合わせて変更することができます。MySQL ソフトウェアは GPL (GNU General Public License)、http://www.fsf.org/licenses/、を使用して、さまざまな状況で実行するものとしないものを定義します。GPL では不都合な場合や商用アプリケーションに MySQL コードを組み込む必要がある場合は、商用ライセンス版を購入することができます。詳細は、MySQL ライセンス情報 (http://www-jp.mysql.com/company/legal/licensing/) を参照してください。

  • MySQL Database Server は非常に高速で信頼性が高く、スケーラブルで使いやすいです。

    それを求めていたのでしたら、ぜひお試しください。MySQL Server は、デスクトップまたはラップトップ上で、ほかのアプリケーションや Web サーバーなどと併用して、ほとんどまたはまったく処理を要することなく快適に実行できます。マシン全体を MySQL 専用にする場合、使用可能なすべてのメモリー、CPU パワー、および I/O 能力を利用するように設定を調整できます。MySQL は、ネットワークで接続されたマシンのクラスターにスケールアップすることもできます。

    ベンチマークページで、ほかのデータベース管理システムと MySQL Server のパフォーマンスを比較することができます。セクション8.12.2「MySQL ベンチマークスイート」を参照してください。

    MySQL Server は当初、既存のソリューションよりもはるかに速く大規模なデータベースを処理することを目的として開発され、多くを要求される運用環境で数年間にわたって使用されています。引き続き開発が行われていますが、MySQL Server は現在、便利で多彩な関数を備えています。その接続性、速度、安全性によって、MySQL Server はインターネット上のデータベースへのアクセスに非常に適しています。

  • MySQL Server は、クライアント/サーバー組み込みシステムで機能します。

    MySQL Database Software は、さまざまなバックエンドをサポートするマルチスレッド形式の SQL Server、複数の異なるクライアントプログラムおよびライブラリ、管理ツール、幅広いアプリケーションプログラミングインタフェース(API)から成るクライアント/サーバーシステムです。

    また、MySQL Server はアプリケーションへのリンクが可能なマルチスレッドライブラリとして提供されており、さらに小規模で高速な、管理しやすいスタンドアロン製品を作り出すことができます。

  • 大量の MySQL ソフトウェアが提供されており、使用可能です。

    MySQL Server には、ユーザーと緊密に協力して開発された、実際的な一連の機能があります。必要なアプリケーションや言語ですでに MySQL Database Server がサポートされていると思われます。

MySQL の正式な読み方は、マイエスキューエル (マイシークエルではありません) ですが、マイシークエルやその他のローカライズされた方法で発音してもかまいません。

1.3.2 MySQL の主な機能

このセクションでは MySQL Database Software の重要な特徴の一部を説明します。ほとんどの場合、ロードマップはすべてのバージョンの MySQL に適用されます。シリーズごとに新しく導入される MySQL の機能については、対応するマニュアルの新機能セクションを参照してください。

内部および移植性

  • C および C++ で記述されています。

  • さまざまなコンパイラでテストされています。

  • さまざまなプラットフォームで動作します。https://www.mysql.com/support/supportedplatforms/database.html を参照してください。

  • 移植性のために、MySQL 5.5 以降では CMake を使用しています。以前のシリーズでは GNU Automake、Autoconf、および Libtool を使用しています。

  • Purify (商用メモリーリーク検出システム) と GPL ツールの Valgrind (http://developer.kde.org/~sewardj/) でテストされています。

  • 独立モジュールを備えた多層サーバー設計を使用しています。

  • カーネルスレッドを使用した完全なマルチスレッドとなるよう設計され、使用可能な場合、複数の CPU を簡単に使用することができます。

  • トランザクションストレージエンジンと非トランザクションストレージエンジンを備えています。

  • インデックス圧縮を備えた非常に高速な B-tree ディスクテーブル(MyISAM) を使用しています。

  • 別のストレージエンジンの追加が比較的容易になるよう設計されています。これは、社内データベースへの SQL インタフェースを追加する場合に便利です。

  • スレッドベースの非常に高速なメモリー割り当てシステムを使用しています。

  • 最適化されたネストループ結合を使用して非常に高速な結合を実行します。

  • インメモリーハッシュテーブルを実装し、一時テーブルとして使用します。

  • 高度に最適化されたクラスライブラリを使用して SQL 関数が実装されるため、最大限の速度が確保されます。通常は、クエリーの初期化後にメモリー割り当てが行われることはありません。

  • クライアント/サーバーネットワーク環境で使用するために、サーバーを独立したプログラムとして提供しています。単独のアプリケーションに組み込み (リンク) できるライブラリとしても提供されています。このようなアプリケーションは単一で、あるいはネットワーク環境の整っていない場所でも使用することができます。

データ型

  • 多数のデータタイプ: 1、2、3、4、および 8 バイト長の符号付き/符号なし整数、FLOATDOUBLECHARVARCHARBINARYVARBINARYTEXTBLOBDATETIMEDATETIMETIMESTAMPYEARSETENUM、および OpenGIS 空間型。第11章「データ型 を参照してください。

  • 固定長および可変長の文字列型。

ステートメントと関数

  • クエリーの SELECT 句および WHERE 句での演算子と関数の完全なサポート。例:

    mysql> SELECT CONCAT(first_name, ' ', last_name) -> FROM citizen -> WHERE income/dependents > 10000 AND age > 30;
  • SQL の GROUP BY 句および ORDER BY 句の完全なサポート。グループ関数 (COUNT()AVG()STD()SUM()MAX()MIN()、および GROUP_CONCAT()) のサポート。

  • 標準の SQL 構文および ODBC 構文での LEFT OUTER JOIN および RIGHT OUTER JOIN のサポート。

  • 標準 SQL で必要な、テーブルおよびカラムにおけるエイリアスのサポート。

  • 変更された (影響を受けた) 行の数を返す DELETEINSERTREPLACE、および UPDATE のサポート。サーバーに接続する際にフラグを設定することで、代わりに一致したレコードの数を返すことも可能です。

  • データベース、ストレージエンジン、テーブル、およびインデックスに関する情報を取得する、MySQL 固有の SHOW ステートメントのサポート。MySQL 5.0 では、INFORMATION_SCHEMA データベースのサポートも、標準 SQL に基づき追加されています。

  • オプティマイザによるクエリーの解決方法を表示する EXPLAIN ステートメント。

  • 関数名の、テーブル名やカラム名との独立性。たとえば、ABS は有効なカラム名です。唯一の制限事項は、関数呼び出しで、関数名とその後に続く ( との間にスペースを使用できないことです。セクション9.3「予約語」を参照してください。

  • 同じステートメント内で、さまざまなデータベースのテーブルを参照することができます。

セキュリティー

  • 非常に柔軟でセキュアな権限およびパスワードシステム。ホストベースの検証が可能です。

  • サーバーに接続する際にすべてのパスワードトラフィックが暗号化されるので、パスワードは安全です。

拡張性と制限

  • 大規模なデータベースのサポート。当社は、MySQL Server を使用して 50,000,000 レコードが格納されたデータベースを処理しています。また、MySQL Server を使用して 200,000 テーブル、約 5,000,000,000 行を処理しているユーザーもいます。

  • 各テーブルで最高 64 個のインデックスをサポートします。(MySQL 4.1.2 では 32 個)。各インデックスは、1 から 16 個のカラムまたはカラムの一部で構成されます。インデックスの最大幅は InnoDB テーブルでは 767 バイト、MyISAM では 1000 バイトです。MySQL 4.1.2 では 500 が限度でした。インデックスでは、CHARVARCHARBLOB、あるいは TEXT 型のカラムのプリフィクスを使用することができます。

接続性

  • クライアントは複数のプロトコルを使用して MySQL Server に接続できます。

    • クライアントは、あらゆるプラットフォームで TCP/IP ソケットを使用して接続することができます。

    • Windows NT ファミリ (NT、2000、XP、2003、または Vista) の Windows システムでは、サーバーが --enable-named-pipe オプションで起動された場合、クライアントは名前付きパイプを使用して接続できます。MySQL 4.1 以降では、--shared-memory オプションで起動されていれば Windows のサーバーは共有メモリー接続もサポートします。クライアントは --protocol=memory オプションを使用して共有メモリーで接続できます。

    • Unix システムでは、クライアントは Unix ドメインソケットファイルを使用して接続することができます。

  • MySQL クライアントプログラムはさまざまな言語で記述できます。C 言語で記述されたクライアントライブラリは C、C++、あるいは C バインディングを提供する任意の言語で記述されたクライアントでも使用可能です。

  • C、C++、Eiffel、Java、Perl、PHP、Python、Ruby、および Tcl 用の API が提供されており、MySQL クライアントを多くの言語で記述できます。第23章「Connector および API を参照してください。

  • Connector/ODBC (MyODBC) インタフェースによって、ODBC (Open DataBase Connectivity) 接続を使用するクライアントプログラムに MySQL サポートが提供されます。たとえば、MS Access を使用して MySQL Server に接続することができます。クライアントは、Windows と Unix のどちらで実行されていてもかまいません。Connector/ODBC ソースが使用可能です。ほかの多くの機能と同様に、ODBC 2.5 のすべての機能がサポートされます。「MySQL Connector/ODBC Developer Guide」を参照してください。

  • Connector/J インタフェースは JDBC 接続を使用する Java クライアントプログラムの MySQL サポートを提供しています。クライアントは、Windows と Unix のどちらで実行されていてもかまいません。Connector/J ソースが使用可能です。「MySQL Connector/J 5.1 Developer Guide」を参照してください。

  • MySQL Connector/Net により、開発者は MySQL 上でセキュアな高性能データ接続性を要する .NET アプリケーションの作成を容易に行えます。必要な ADO.NET インタフェースを実装し、ADO.NET 対応のツールに統合します。開発者は好みの .NET 言語でアプリケーションを構築できます。MySQL Connector/Net は 100% C# で記述され、完全に管理される ADO.NET ドライバです。「MySQL Connector/NET Developer Guide」を参照してください。

ローカライズ

  • サーバーは、クライアントに多数の言語でエラーメッセージを送信することができます。セクション10.2「エラーメッセージ言語の設定」を参照してください。

  • latin1 (cp1252)、germanbig5ujis、などのさまざまな文字セットを完全にサポートします。たとえば、スカンジナビア語の文字 åä、および ö をテーブル名やカラム名で使用できます。ユニコードは MySQL 4.1 以降でサポートされます。

  • すべてのデータが、選択した文字セットで保存されます。

  • ソートと比較は、選択した文字セットと照合順序に基づいて行われます (デフォルトは latin1 とスウェーデン語の照合順序)。これは、MySQL Server の起動時に変更することができます。非常に高度なソートの例については、チェコ語のソートコードを参照してください。MySQL Server ではさまざまな文字セットがサポートされており、コンパイル時および実行時に指定することができます。

  • MySQL 4.1 では、サーバーのタイムゾーンは動的に変更可能で、各クライアントは独自のタイムゾーンを指定できます セクション10.6「MySQL Server でのタイムゾーンのサポート」

クライアントとツール

  • MySQL には複数のクライアントとユーティリティープログラムが含まれます。これには、mysqldump および mysqladmin といったコマンド行プログラム、そして MySQL Workbench などのグラフィックプログラムも含まれます。

  • MySQL Server には、テーブルのチェック、最適化、および修復を行う SQL ステートメントのサポートが組み込まれています。これらのステートメントは、mysqlcheck クライアントを介してコマンド行から使用可能です。また、MySQL には、MyISAM テーブルでこれらの操作を実行するための myisamchk という非常に高速なコマンド行ユーティリティーが組み込まれています。第4章「MySQL プログラム を参照してください。

  • MySQL プログラムを --help または -? オプションを指定して呼び出すと、オンラインヘルプを参照できます。

1.3.3 MySQL の歴史

当初は、高速で低レベルな独自の (ISAM) ルーチンを使用してテーブルに接続するために mSQL データベースシステムを使用するつもりでした。しかし、いくつかのテストを行なった結果、mSQL はそれほど高速でも柔軟でもないため、ニーズに合わないという結論に至りました。これが要因となって、私たちのデータベースへの新しい SQL インタフェースを開発することになりました。ただし、mSQL とほとんど同じ API インタフェースを使用することにしました。この API は、mSQL で使用するために記述されたサードパーティーのコードを MySQL で使用するために簡単に移植できるように設計されています。

MySQL は、共同創設者 Monty Widenius の娘の My にちなんで名づけられました。

MySQL のドルフィン (当社のロゴ) の名前は Sakila, です。ドルフィンのネーミングコンテストで、ユーザーによって提案された膨大な数の名前の中から選ばれました。採用された名前を提案したのは、アフリカのスワジランド出身の Ambrose Twebaze というオープンソースソフトウェアの開発者でした。Ambrose によると、Sakila という女性の名前は、スワジランドの現地語であるシスワティ語にルーツがあるということです。また、Sakila は、Ambrose の出生国であるウガンダに近い、タンザニアのアルーシャにある町の名前でもあります。

1.4 MySQL 5.6 の新機能

このセクションでは、MySQL 5.6 で追加された機能、非推奨になった機能、および削除された機能について要約しています。

追加された機能

次の機能が、MySQL 5.6 に追加されました。

  • セキュリティーの改善  次のセキュリティーの改善が行われました。

    • MySQL に、.mylogin.cnf という名前のオプションファイルに認証証明書を暗号化して格納する方法が用意されました。このファイルを作成するには、mysql_config_editor ユーティリティーを使用します。MySQL クライアントプログラムがあとからこのファイルを読み取って、MySQL Server に接続するための認証証明書を取得することができます。mysql_config_editor は、暗号化を使用して .mylogin.cnf ファイルを作成するため、証明書は平文として格納されず、その内容はクライアントプログラムによって復号化されると、メモリー内でのみ使用されます。このように、パスワードは平文でない形式でファイルに格納でき、コマンド行または環境変数で表示する必要もなくあとから使用できます。詳細は、セクション4.6.6「mysql_config_editor — MySQL 構成ユーティリティー」を参照してください。

    • MySQL は、SHA-256 パスワードハッシングを実装する sha256_password という名前の認証プラグインを通じて利用できる、ユーザーアカウントパスワードのより強力な暗号化をサポートするようになりました。このプラグインは組み込まれているため、常に使用でき、明示的にロードする必要はありません。SHA-256 パスワードを使用するアカウントを作成する手順などの詳細は、セクション6.3.8.4「SHA-256 認証プラグイン」を参照してください。

    • mysql.user テーブルに password_expired カラムが追加されました。そのデフォルト値は 'N' ですが、新しい ALTER USER ステートメントでは 'Y' に設定できます。アカウントのパスワードの有効期限が切れたあと、そのアカウントを使用したサーバーへの以降の接続で操作を実行すると、ユーザーが SET PASSWORD ステートメントを発行して、新しいアカウントパスワードを確立するまで、すべての場合でエラーになります。詳細は、セクション13.7.1.1「ALTER USER 構文」およびセクション6.3.6「パスワードの期限切れとサンドボックスモード」を参照してください。

    • MySQL にはパスワードセキュリティーのチェック対策が施されました。

      • 平文の値として指定されるパスワードを割り当てるステートメントで、値は現在のパスワードポリシーと照合して検査され、弱い場合は拒否されます (ステートメントは ER_NOT_VALID_PASSWORD エラーを返します)。これは、CREATE USERGRANT、および SET PASSWORD ステートメントに影響します。PASSWORD() および OLD_PASSWORD() 関数への引数として指定されるパスワードも検査されます。

      • パスワード候補の強度は、新しい VALIDATE_PASSWORD_STRENGTH() SQL 関数を使用して評価できます。これは、パスワード引数を取得して、0 (弱い) から 100 (強い) の整数を返します。

      どちらの機能も validate_password プラグインで実装されます。詳細は、セクション6.1.2.6「パスワード検証プラグイン」を参照してください。

    • mysql_upgrade は、4.1 以前の古いハッシング方法でハッシングされたパスワードを持つユーザーアカウントを見つけた場合、警告を発するようになりました。このようなアカウントは、よりセキュアなパスワードハッシングを使用するように更新する必要があります。セクション6.1.2.4「MySQL でのパスワードハッシュ」を参照してください。

    • Unix プラットフォームでは、mysql_install_db は、よりセキュアな MySQL インストールを実現する新しいオプションである --random-passwords をサポートします。--random-passwords を付けて mysql_install_db を呼び出すと、ランダムパスワードが MySQL root アカウントに割り当てられ、これらのアカウントに対して有効期限切れパスワードフラグが設定され、匿名ユーザー MySQL アカウントが削除されます。追加情報についてはセクション4.4.3「mysql_install_db — MySQL データディレクトリの初期化」を参照してください。

    • パスワードが平文で一般クエリーログ、スロークエリーログ、およびバイナリログに書き込まれたステートメントに表示されないように、ロギングが変更されました。セクション6.1.2.3「パスワードおよびロギング」を参照してください。

      mysql クライアントは、パスワードを参照するその履歴ファイルステートメントに記録しないようになりました。セクション4.5.1.3「mysql のロギング」を参照してください。

    • START SLAVE 構文は、マスターへの接続に接続パラメータを指定できるように変更されました。これは、master.info ファイルにパスワードを格納する代替方法になります。セクション13.4.2.5「START SLAVE 構文」を参照してください。

  • MySQL Enterprise  監査ログプラグインで生成されたファイルの形式は、Oracle Audit Vault との互換性が高くなるように変更されました。セクション6.3.12「MySQL Enterprise Audit ログプラグイン」およびセクション6.3.12.3「監査ログファイル」を参照してください。

    MySQL Enterprise Edition には、SQL レベルでの OpenSSL 機能を公開している OpenSSL ライブラリに基づいて、一連の暗号化関数が含まれるようになりました。これらの関数を使用することによって、エンタープライズアプリケーションが次の操作を実行できるようになります。

    • 公開鍵非対称暗号方式を使用した、追加のデータ保護の実装

    • 公開鍵、秘密鍵、およびデジタル署名の作成

    • 非対称暗号化および非対称復号化の実行

    • デジタル署名およびデータの検証や妥当性検査に対する暗号化ハッシュの使用

    詳細は、セクション12.17「MySQL Enterprise Encryption の関数」を参照してください。

    MySQL Enterprise Edition に含まれる監査ログプラグインには、ユーザーアカウントおよびイベントステータスに基づいて監査イベントをフィルタリングする機能が用意されました。複数の新しいシステム変数は、DBA にフィルタリング制御をもたらします。さらに、複数のステータス変数の追加によって、監査ログプラグインレポート機能が改善されました。詳細は、セクション6.3.12.4「監査ログプラグインのロギング制御」およびセクション6.3.12.7「監査ログプラグインのステータス変数」を参照してください。

  • サーバーデフォルトに対する変更  MySQL 5.6.6 以降では、MySQL Server のいくつかのデフォルトパラメータが、前のリリースのデフォルト値と異なっています。これらの変更の目的は、初期設定のままで優れたパフォーマンスを提供し、データベース管理者が設定を手動で変更することの必要性を低下させることです。詳細は、セクション5.1.2.1「サーバーのデフォルト値への変更」を参照してください。

  • InnoDB の拡張機能  次の InnoDB の拡張機能が追加されました。

    • InnoDB テーブル上に FULLTEXT インデックスを作成し、MATCH() ... AGAINST 構文を使用してそれらのクエリーを実行できます。この機能には、新しい近似検索演算子 (@) と、複数の新しい構成オプションおよび INFORMATION_SCHEMA テーブルが含まれます。詳細は、セクション14.2.13.3「FULLTEXT インデックス」を参照してください。

    • テーブルをコピーせず、テーブルへの挿入、更新、および削除をブロックせず、またはその両方を行わずに、複数の ALTER TABLE 操作を実行できます。これらの拡張機能はまとめて、オンライン DDL と呼ばれています。詳細は、セクション14.11「InnoDB とオンライン DDL」を参照してください。

    • InnoDB は、MySQL データディレクトリ外の場所で InnoDBfile-per-table テーブルスペース (.ibd ファイル) を作成できるようにする、CREATE TABLE ステートメントの DATA DIRECTORY='directory' 句をサポートするようになりました。この拡張機能は、サーバー環境により適切に適合する場所に file-per-table テーブルスペースを作成できる柔軟性をもたらします。たとえば、ビジーテーブルを SSD デバイス上に、または大きなテーブルを大容量 HDD デバイス上に配置できます。

      詳細は、セクション14.5.4「テーブルスペースの位置の指定」を参照してください。

    • InnoDB は、トランスポータブルテーブルスペースの概念をサポートするようになり、バッファーされたデータ、進行中のトランザクション、およびスペース IDLSN などの内部管理詳細によって不整合や不一致が起きることなく、実行中の MySQL インスタンスから file-per-table テーブルスペース (.ibd ファイル) をエクスポートし、別の実行中のインスタンスにインポートできます。

      FLUSH TABLE コマンドの FOR EXPORT 句は、未保存のあらゆる変更内容を InnoDB メモリーバッファーから .ibd ファイルに書き込みます。.ibd ファイルと個別のメタデータファイルを別のサーバーにコピーしたあと、ALTER TABLE ステートメントの DISCARD TABLESPACE 句と IMPORT TABLESPACE 句が、別の MySQL インスタンスにテーブルデータをもたらすために使用されます。

      この拡張機能は、サーバー環境により適切に適合できるように、file-per-table テーブルスペースを自由に移動できる柔軟性をもたらします。たとえば、ビジーテーブルを SSD デバイス上に、または大きなテーブルを大容量 HDD デバイス上に移動できます。詳細は、セクション14.5.5「テーブルスペースの別のサーバーへのコピー (トランスポータブルテーブルスペース)」を参照してください。

    • 非圧縮テーブルの InnoDBページサイズを、デフォルトの 16K バイトに代わるサイズとして、8K バイトまたは 4K バイトに設定できるようになりました。この設定は、innodb_page_size 構成オプションで制御されます。このサイズは MySQL インスタンスの作成時に指定します。インスタンス内のすべての InnoDBテーブルスペースは同じページサイズを共有します。ページサイズが小さくなると、ワークロードとストレージデバイスとの特定の組み合わせ、特にブロックサイズの小さな SSD デバイスとの組み合わせについて、冗長または非効率的な I/O を回避できるようになります。

    • 適応型フラッシュのアルゴリズムに対する改善により、さまざまなワークロード下での I/O 操作の効率性と整合性が向上します。新しいアルゴリズムとデフォルトの構成値は、ほとんどのユーザーにとって、パフォーマンスと並列性を改善すると考えられています。上級ユーザーは、複数の構成オプションを通じて、I/O 応答性を微調整できます。詳細は、セクション14.13.1.6「InnoDB バッファープールのフラッシュのチューニング」を参照してください。

    • NoSQL スタイルの API を通じて、InnoDB テーブルにアクセスする MySQL アプリケーションをコード化できます。この機能は、普及している memcached デーモンを使用して、鍵と値のペアに ADDSETGET などのリクエストをリレーします。データを格納および取得するこれらの単純な操作により、クエリー実行計画の解析や構築などの SQL オーバーヘッドが回避されます。NoSQL API および SQL を通じて同じデータにアクセスできます。たとえば、高速な更新および検索に NoSQL API を、複雑なクエリーおよび既存のアプリケーションとの互換性に SQL を使用できます。詳細は、セクション14.18「InnoDB と memcached の統合」を参照してください。

    • InnoDB テーブルのオプティマイザ統計は、より予測可能な間隔で収集され、サーバーの再起動にまたがって維持でき、計画安定性が向上します。オプティマイザ統計の精度を高め、クエリー実行計画を改善するように、InnoDB インデックスに対して行われるサンプル収集の量を制御することもできます。詳細は、セクション14.13.16.1「永続的オプティマイザ統計のパラメータの構成」を参照してください。

    • 新しい最適化は、読み取り専用のトランザクションに適用され、アドホッククエリーとレポート生成アプリケーションのパフォーマンスと並列性を改善します。可能な場合にはこれらの最適化は自動的に適用されます。または、START TRANSACTION READ ONLY を指定してトランザクションが読み取り専用になるようにすることができます。詳細は、セクション14.13.14「InnoDB の読み取り専用トランザクションの最適化」を参照してください。

    • InnoDBUndo ログを、システムテーブルスペースから 1 つ以上の個別のテーブルスペースに移動できます。Undo ログの I/O パターンは、ハードディスクストレージにシステムテーブルスペースを保持しながら、これらの新しいテーブルスペースを、SSD ストレージに移動する適切な候補にします。詳細は、セクション14.5.6「個別のテーブルスペースへの InnoDB Undo ログの格納」を参照してください。

    • より高速なチェックサムアルゴリズムを有効にする構成オプション innodb_checksum_algorithm=crc32 を指定することによって、InnoDB チェックサム機能の効率性を改善できます。このオプションは innodb_checksums オプションを置き換えます。古いチェックサムアルゴリズム (オプション値 innodb) を使用して書き込まれたデータは完全に上方互換性があります。新しいチェックサムアルゴリズム (オプション値 crc32) を使用して変更されたテーブルスペースは、innodb_checksum_algorithm オプションをサポートしない以前のバージョンの MySQL にダウングレードできません。

    • InnoDBRedo ログファイルの最大合計サイズは、4G バイトから 512G バイトに増大しました。innodb_log_file_size オプションで、さらに大きな値を指定できます。既存の Redo ログファイルのサイズが innodb_log_file_size および innodb_log_files_in_group で指定されたサイズと一致しない状況を、起動動作で自動処理するようになりました。

    • --innodb-read-only オプションを使用すると、MySQL Server を読み取り専用モードで実行できます。DVD や CD などの読み取り専用メディア上の InnoDB テーブルにアクセスすることも、すべて同じデータディレクトリを共有する複数のインスタンスを含むデータウェアハウスを設定できます。使用法の詳細は、セクション14.3.1「読み取り専用操作用の InnoDB の構成」を参照してください。

    • 新しい構成オプション innodb_compression_level では、zlib で使用する 0-9 の範囲から、InnoDB 圧縮テーブルの圧縮レベルを選択できます。更新操作によってページが再度圧縮されるときに、バッファープール内の圧縮ページが Redo ログに格納されるかどうかを制御することもできます。この動作は、innodb_log_compressed_pages 構成オプションで制御されます。

    • InnoDB圧縮テーブル内のデータブロックには、一定量の空スペース (パディング) が含まれ、DML 操作は、新しい値を再圧縮することなく、行データを変更できます。パディングが多すぎると、大きな変更後にデータを再圧縮する必要があるときに、圧縮が失敗する可能性が増え、ページの分割が必要になる可能性があります。パディングの量を動的に調整できるようになったため、DBA は、新しいパラメータでテーブル全体を再作成したり、ページサイズの異なるインスタンス全体を再作成したりすることなく、圧縮の失敗の割合を低減できるようになりました。関連した新しい構成オプションは、innodb_compression_failure_threshold_pctinnodb_compression_pad_pct_max です。

    • 複数の新しい InnoDB 関連の INFORMATION_SCHEMA テーブルは、InnoDB バッファープールに関する情報、テーブル、インデックス、および InnoDB データディクショナリからの外部キーに関するメタデータ、パフォーマンススキーマテーブルからの情報を補完するパフォーマンスメトリックに関する低レベル情報を提供します。

    • 膨大な数のテーブルを含むシステムでのメモリーロードを簡単にするために、InnoDB は、もっとも長い間アクセスされずに経過したテーブルを選択する LRU アルゴリズムを使用して、開いているテーブルに関連付けられたメモリーを解放するようになりました。開いた InnoDB テーブルのメタデータを保持するためにより多くのメモリーを予約するには、table_definition_cache 構成オプションの値を増やしてください。InnoDB は、InnoDB データディクショナリキャッシュ内の開いているテーブルインスタンスの数に関するソフト制限として、この値を扱います。追加情報については、table_definition_cache のドキュメントを参照してください。

    • InnoDB には、カーネルミューテックスの分割による競合の軽減、メインスレッドから個別のスレッドへのフラッシュ操作の移動、複数のパージスレッドの有効化、大容量メモリーシステムでのバッファープールの競合の軽減などの、複数の内部パフォーマンス拡張機能があります。

    • InnoDB は、高速な新しいアルゴリズムを使用して、deadlocks を検出します。すべての InnoDB デッドロックに関する情報は、MySQL Server エラーログに書き込むことができ、アプリケーション問題の診断に役立ちます。

    • サーバー再起動後の長時間のウォームアップを回避するために、特に大きな InnoDBバッファープールを伴うインスタンスの場合は、再起動直後にバッファープールにページをリロードできます。MySQL は、シャットダウン時にコンパクトなデータファイルをダンプし、続いてそのデータファイルを参照して、次回の再起動時にリロードするページを見つけることができます。ベンチマーキング中や複雑なレポート生成クエリー後など、いつでもバッファープールを手動でダンプまたはリロードすることもできます。詳細は、セクション14.13.1.5「再起動を高速化するための InnoDB バッファープールのプリロード」を参照してください。

    • MySQL 5.6.16 以降、innochecksum は 2G バイト以上のサイズのファイルのサポートに対応しています。以前は、innochecksum は 2G バイトまでのサイズのファイルだけをサポートしていました。

    • MySQL 5.6.16 以降では、新しいグローバル構成パラメータ innodb_status_output および innodb_status_output_locks を使用すると、標準の InnoDB Monitor および InnoDB Lock Monitor を動的に有効および無効にすることができます。特別な名前が付けられたテーブルを作成および削除することによって、定期的な出力のモニターを有効および無効にする方法は非推奨であり、今後のリリースで削除される可能性があります。追加情報については、セクション14.15「InnoDB モニター」を参照してください。

    • MySQL 5.6.17 以降、MySQL は、次の操作にオンライン DDL (ALGORITHM=INPLACE) を使用した通常のパーティション化された InnoDB テーブルの再構築をサポートします。

      • OPTIMIZE TABLE

      • ALTER TABLE ... FORCE

      • ALTER TABLE ... ENGINE=INNODB (InnoDB テーブルで実行した場合)

      オンライン DDL のサポートにより、テーブル再構築時間が短縮し、ユーザーアプリケーションの停止時間の短縮に役立つ並列 DML が可能になります。詳細は、セクション14.11.1「オンライン DDL の概要」を参照してください。

  • パーティション化  次のテーブルパーティション化拡張機能が追加されました。

    • パーティションの最大数は 8192 まで増加しています。これは、テーブルのすべてのパーティションとすべてのサブパーティションを含めた数字です。

    • ALTER TABLE ... EXCHANGE PARTITION ステートメントを使用して、パーティション化されたテーブルのパーティションまたはサブパーティション化されたテーブルのサブパーティションを、パーティション化されていないことを除けば同じ構造のテーブルと交換できるようになりました。これはたとえば、パーティションのインポートおよびエクスポートに使用できます。詳細および例については、セクション19.3.3「パーティションとサブパーティションをテーブルと交換する」を参照してください。

    • パーティション化されたテーブルで機能するクエリーや多数のデータ変更ステートメントで、1 つ以上のパーティションまたはサブパーティションの明示的な選択がサポートされるようになりました。たとえば、整数カラム c を含むテーブル t に、p0p1p2、および p3 という名前の 4 つのパーティションがあるとします。この場合、クエリー SELECT * FROM t PARTITION (p0, p1) WHERE c < 5 は、パーティション p0 および p1 から、c が 5 未満である行だけを返します。

      次のステートメントは、明示的なパーティション選択をサポートします。

      • SELECT

      • DELETE

      • INSERT

      • REPLACE

      • UPDATE

      • LOAD DATA

      • LOAD XML

      構文については、個々のステートメントの説明を参照してください。追加情報および例については、セクション19.5「パーティション選択」を参照してください。

    • パーティションロックプルーニングは、多くのパーティションを含むテーブル上で機能する多数の DML および DDL ステートメントのパフォーマンスを大幅に改善しますが、これは、これらのステートメントの影響を受けないパーティション上のロックを除去できるようにすることによって行います。このようなステートメントには、SELECTSELECT ... PARTITIONUPDATEREPLACEINSERT などの多数のステートメントが含まれます。この結果パフォーマンスが改善されたステートメントの全リストなどの詳細は、セクション19.6.4「パーティショニングとロック」を参照してください。

  • パフォーマンススキーマ  パフォーマンススキーマには、次のような複数の新機能が含まれています。

    • テーブル入力および出力のインストゥルメンテーション。インストゥルメントされた操作には、永続的ベーステーブルまたは一時テーブルへの行レベルのアクセスが含まれます。行に影響する操作は、フェッチ、挿入、更新、および削除です。

    • スキーマ名またはテーブル名に基づいた、テーブルによるイベントフィルタリング。

    • スレッドによるイベントフィルタリング。スレッドに関する詳細が収集されます。

    • テーブルおよびインデックス I/O 用とテーブルロック用のサマリーテーブル。

    • ステートメントとステートメント内のステージのインストゥルメンテーション。

    • サーバーの起動時のインストゥルメントとコンシューマの構成。以前は実行時にのみ可能でした。

  • MySQL Cluster  MySQL Cluster は個別の製品としてリリースされます。最新の GA リリースは MySQL 5.6 に基づき、バージョン 7.3 の NDB ストレージエンジンを使用しています。クラスタリングのサポートは、主要な MySQL Server 5.6 リリースでは利用できません。MySQL Cluster NDB 7.3 の詳細は、第18章「MySQL Cluster NDB 7.3 および MySQL Cluster NDB 7.4を参照してください。最新の開発バージョンは、バージョン 7.4 の NDB ストレージエンジンと MySQL Server 5.6 に基づいた、MySQL Cluster NDB 7.4 です。現在、MySQL Cluster NDB 7.4 はテストおよび評価のために使用できます。最新の MySQL Cluster NDB 7.4 リリースは https://dev.mysql.com/downloads/cluster/ から入手できます。

    詳細および MySQL Cluster NDB 7.4 で行われた改善の概要については、セクション18.1.4.2「MySQL Cluster NDB 7.4 での MySQL Cluster の開発」を参照してください。

  • レプリケーションとロギング  次のレプリケーション拡張機能が追加されました。

    • MySQL は、グローバルトランザクション識別子 (GTIDとも呼ばれます) を使用したトランザクションベースのレプリケーションをサポートするようになりました。これにより、発信サーバー上でコミットされ、いずれかのスレーブによって適用されたときに、各トランザクションの識別と追跡が可能になります。

      レプリケーションの設定で GTID を有効にする場合、主に --gtid-mode および --enforce-gtid-consistency の新しいサーバーオプションを使用して行います。GTID のサポートで導入された追加オプションおよび変数の詳細は、セクション17.1.4.5「グローバルトランザクション ID のオプションと変数」を参照してください。

      GTID を使用する場合、新しいスレーブを開始したり、新しいマスターにフェイルオーバーするときに、ログファイルやこれらのファイル内での位置を参照したりする必要はありません。このため、これらのタスクが非常に簡略化されます。バイナリログファイルを参照して、または参照せずに、GTID レプリケーションに対してサーバーをプロビジョニングする場合の詳細は、セクション17.1.3.3「フェイルオーバーおよびスケールアウトでの GTID の使用」を参照してください。

      GTID ベースのレプリケーションは完全にトランザクションベースであるため、マスターとスレーブの一貫性のチェックが簡単になります。所定のマスター上でコミットされたすべてのトランザクションが、所定のスレーブ上でもコミットされている場合、2 台のサーバー間の一貫性は保証されます。

      MySQL Replication での GTID の実装および使用についてさらに詳しい情報が必要な場合は、セクション17.1.3「グローバルトランザクション識別子を使用したレプリケーション」を参照してください。

    • MySQL の行ベースのレプリケーションは、行イメージコントロールをサポートするようになりました。各行の変更に対し、すべてのカラムではなく、それぞれの行での変更を一意に識別および実行するために必要なカラムだけを記録することによって、ディスク容量、ネットワークリソース、およびメモリー使用量を節約できます。binlog_row_image サーバーシステム変数を、minimal (必要なカラムだけを記録)、full (すべてのカラムを記録)、noblob (不要な BLOB または TEXT カラムを除いたすべてのカラムを記録) のいずれかの値に設定することによって、すべての行を記録するか、最低限の行を記録するかを指定できます。詳細は、バイナリロギングで使用されるシステム変数を参照してください。

    • MySQL Server で書き込まれ、読み取られるバイナリログは、完全なイベント (トランザクション) だけが記録されたり読み戻されたりするため、クラッシュセーフになりました。デフォルトで、サーバーはイベント自体のほかにイベントの長さを記録し、この情報を使用して、イベントが正しく書き込まれたことを検証します。binlog_checksum システム変数を設定することによって、サーバーで、CRC32 チェックサムを使用してイベントのチェックサムを書き込ませることもできます。サーバーにバイナリログからチェックサムを読み取らせるには、master_verify_checksum システム変数を使用します。--slave-sql-verify-checksum システム変数は、スレーブ SQL スレッドに、リレーログからチェックサムを読み取らせます。

    • MySQL は、テーブルおよびファイルへのマスター接続情報のロギングと、スレーブリレーログ情報のロギングをサポートするようになりました。これらのテーブルの使用は、--master-info-repository--relay-log-info-repository のサーバーオプションによって別々に制御できます。--master-info-repositoryTABLE に設定すると、接続情報が slave_master_info テーブルに記録されます。--relay-log-info-repositoryTABLE に設定すると、リレーログ情報が slave_relay_log_info テーブルに記録されます。これらのテーブルはどちらも、mysql システムデータベース内に自動的に作成されます。

      レプリケーションをクラッシュセーフにするには、slave_master_info テーブルと slave_relay_log_info テーブルがそれぞれ、トランザクションストレージエンジンを使用する必要があります。この理由のため、MySQL 5.6.6 以降では、これらのテーブルは InnoDB を使用して作成されます。(Bug #13538891) これらの両方のテーブルで MyISAM を使用している以前の MySQL 5.6 リリースを使用している場合は、レプリケーションがクラッシュセーフであることを望むならば、レプリケーションを開始する前に、両方をトランザクションストレージエンジン (InnoDB など) に変換する必要があることになります。このような場合は、適切な ALTER TABLE ... ENGINE=... ステートメントを使用して、これを行えます。レプリケーションが実際に実行している間、これらのテーブルのどちらかが使用するストレージエンジンを変更しようとしないでください。

      詳細は、クラッシュセーフレプリケーションを参照してください。

    • mysqlbinlog には、そのオリジナルのバイナリ形式でバイナリログをバックアップする機能が用意されました。mysqlbinlog は、--read-from-remote-server オプションと --raw オプションを付けて呼び出された場合、サーバーに接続し、ログファイルをリクエストし、元のファイルと同じ形式で出力ファイルを書き込みます。セクション4.6.8.3「バイナリログファイルのバックアップのための mysqlbinlog の使用」を参照してください。

    • MySQL は、スレーブサーバーが少なくとも指定した時間だけ意図的にマスターに遅れるような遅延レプリケーションをサポートするようになりました。デフォルトの遅延は 0 秒です。CHANGE MASTER TO の新しい MASTER_DELAY オプションを使用して、遅延を設定します。

      遅延レプリケーションは、マスターでのユーザーの誤りから保護したり (DBA は遅延スレーブを災害の直前の時間までロールバックできます)、遅れがあるときのシステムの動作をテストしたりするなどの目的に使用できます。セクション17.3.9「遅延レプリケーション」を参照してください。

    • CHANGE MASTER TO ステートメントの発行時に MASTER_BIND オプションを使用することによって、複数のネットワークインタフェースがあるレプリケーションスレーブに、これらのうち 1 つだけを使用させられるようになりました。

    • log_bin_basename システム変数が追加されました。この変数には、完全なファイル名と、バイナリログファイルへのパスが含まれます。log_bin システム変数はバイナリロギングが有効かどうかだけを示しますが、log_bin_basename--log-bin サーバーオプションで設定された名前を反映します。

      同様に、relay_log_basename システム変数は、ファイル名と、リレーログファイルへの完全パスを示します。

    • MySQL Replication は、スレーブ上でのマルチスレッドを使用したトランザクションの並列実行をサポートするようになりました。並列実行が有効な場合、スレーブ SQL スレッドは、slave_parallel_workers サーバーシステム変数の値によって決定される、多数のスレーブワーカースレッドに対する調整役として機能します。スレーブでのマルチスレッドの現在の実装は、データと更新がデータベースごとにパーティション化されていることと、所定のデータベース内の更新が、マスター上の場合と同じ相対的順序で行われることを前提としています。ただし、異なるデータベース間でトランザクションを調整する必要はありません。この場合、トランザクションもデータベースごとに配分できます。つまり、スレーブ上のワーカースレッドは、別のデータベースへの更新が完了するまで待機せずに、所定のデータベースで連続してトランザクションを処理できます。

      別々のデータベースに対するトランザクションは、スレーブとマスターとでは実行順序が異なることがあるため、単に直近で実行したトランザクションを確認するだけでは、マスター上の以前のすべてのトランザクションがスレーブ上で実行されたという保証にはなりません。これは、マルチスレッド化したスレーブを使用する場合にロギングとリカバリに影響します。スレーブ上でマルチスレッドを使用したときにバイナリロギング情報をどのように解釈すればよいかについては、セクション13.7.5.35「SHOW SLAVE STATUS 構文」を参照してください。

  • オプティマイザの拡張機能  クエリーオプティマイザで次の改善が実装されました。

    • オプティマイザは、次の形式のクエリー (およびサブクエリー) をより効率よく処理できるようになりました。

      SELECT ... FROM single_table ... ORDER BY non_index_column [DESC] LIMIT [M,]N;

      この種のクエリーは、大きな結果セットの数行だけを表示する Web アプリケーションで一般的なものです。例:

      SELECT col1, ... FROM t1 ... ORDER BY name LIMIT 10;
      SELECT col1, ... FROM t1 ... ORDER BY RAND() LIMIT 15;

      ソートバッファーには、sort_buffer_size のサイズが入ります。N 行のソート要素が、ソートバッファー (M が指定された場合は M+N 行) に収まる程度に小さい場合は、サーバーはマージファイルの使用を避けて、メモリー内全体でソートを実行できます。詳細は、セクション8.2.1.19「LIMIT クエリーの最適化」を参照してください。

    • オプティマイザは、Disk-Sweep Multi-Range Read を実装します。セカンダリインデックスでの範囲スキャンを使用して行を読み取ると、テーブルが大きく、ストレージエンジンのキャッシュに格納されていない場合、ベーステーブルへのランダムディスクアクセスが多発する結果になることがあります。Disk-Sweep Multi-Range Read (MRR) 最適化を使用すると、MySQL は、最初にインデックスだけをスキャンし、該当する行のキーを収集することによって、範囲スキャンのランダムディスクアクセスの回数を軽減しようとします。続いてキーがソートされ、最後に主キーの順序を使用してベーステーブルから行が取得されます。Disk-Sweep MRR の目的は、ランダムディスクアクセスの回数を減らし、その代わりに、ベーステーブルデータの順次スキャンを増やすことです。詳細は、セクション8.2.1.13「Multi-Range Read の最適化」を参照してください。

    • オプティマイザは、MySQL がインデックスを使用してテーブルから行を取得する場合の最適化として、Index Condition Pushdown (ICP) を実装します。ICP を使用しない場合、ストレージエンジンはインデックスをトラバースして、ベーステーブル内で行を検索し、MySQL Server に返し、MySQL Server が行に対して WHERE 条件を評価します。ICP を有効にすると、インデックスからのフィールドだけを使用して WHERE 条件の部分を評価できる場合は、MySQL Server はこの WHERE 条件の部分をストレージエンジンにプッシュダウンします。ストレージエンジンは続いて、インデックスエントリを使用することによって、プッシュされたインデックス条件を評価し、これが満たされた場合にのみ、ベース行が読み取られます。ICP は、ストレージエンジンがベーステーブルに対して行う必要のあるアクセスの回数と、MySQL Server がストレージエンジンに対して行う必要のあるアクセスの回数を軽減できます。詳細は、セクション8.2.1.6「インデックスコンディションプッシュダウンの最適化」を参照してください。

    • EXPLAIN ステートメントは、DELETEINSERTREPLACE、および UPDATE のステートメントの実行プラン情報を提供するようになりました。以前には、EXPLAINSELECT ステートメントの情報だけを提供していました。さらに、EXPLAIN ステートメントは JSON 形式で出力を生成できるようになりました。セクション13.8.2「EXPLAIN 構文」を参照してください。

    • FROM 句内でのサブクエリー (つまり派生テーブル) のオプティマイザによる処理の効率性が向上しました。FROM 句内のサブクエリーのマテリアライズはクエリー実行中にその内容が必要になるまで延期されるため、パフォーマンスが向上します。さらに、クエリー実行中に、オプティマイザは派生テーブルにインデックスを追加して、そこからの行の取得速度を上げることができます。詳細は、セクション8.2.1.18.3「FROM 句内のサブクエリー (派生テーブル) の最適化」を参照してください。

    • オプティマイザは、準結合とマテリアライズ戦略を使用して、サブクエリーの実行を最適化します。セクション8.2.1.18.1「準結合変換によるサブクエリーの最適化」およびセクション8.2.1.18.2「サブクエリー実体化によるサブクエリーの最適化」を参照してください。

    • 結合したテーブルと結合バッファーの両方にインデックスアクセスを使用する、Batched Key Access (BKA) 結合アルゴリズムが利用できるようになりました。BKA アルゴリズムは、ネスト外部結合とネスト準結合を含め、内部結合、外部結合、および準結合操作をサポートします。BKA には、テーブルスキャンの効率性の向上による結合パフォーマンスの改善というメリットもあります。詳細は、セクション8.2.1.14「Block Nested Loop 結合と Batched Key Access 結合」を参照してください。

    • オプティマイザに、主に開発者が使用するためのトレース機能が装備されました。一連の optimizer_trace_xxx システム変数と INFORMATION_SCHEMA.OPTIMIZER_TRACE テーブルによってインタフェースが提供されます。詳細については、「MySQL Internals: Tracing the Optimizer」を参照してください。

  • 条件処理  MySQL は GET DIAGNOSTICS ステートメントをサポートするようになりました。GET DIAGNOSTICS は、以前の SQL ステートメントが例外を生成したかどうかや、それが何だったかなどの情報を診断領域から取得するための標準化された方法をアプリケーションにもたらします。詳細は、セクション13.6.7.3「GET DIAGNOSTICS 構文」を参照してください。

    さらに、MySQL の動作が標準 SQL にさらに類似するように、条件ハンドラ処理ルールでの複数の欠陥が修正されました。

    • 選択するハンドラを決定するときにブロックスコープが使用されます。以前には、ストアドプログラムが、ハンドラ選択の単一のスコープを持つものとして扱われていました。

    • 条件の優先順位は、より正確に解決されるようになりました。

    • 診断領域のクリアーが変更されました。Bug #55843 のために、ハンドラを有効にする前に、処理される条件が診断領域からクリアーされていました。これにより、条件の情報がハンドラ内で利用できなくなっていました。現在、条件情報はハンドラで利用できるようになり、ハンドラは GET DIAGNOSTICS ステートメントでこの情報を調べることができます。ハンドラの実行中にまだクリアーされていない条件情報は、ハンドラが終了するときにクリアーされます。

    • 以前には、ハンドラは、条件が発生するとすぐに有効になっていました。現在、条件が発生したステートメントの実行が終了するまで有効にならず、終了した時点でもっとも適切なハンドラが選択されるようになりました。これは、ステートメントの実行中にあとから発生した条件がその前に発生した条件より高い優先順位を持ち、どちらの条件のハンドラも同じスコープにある場合、複数の条件を発生させるステートメントに影響することがあります。以前には、最初に発生した条件のハンドラが、ほかのハンドラより優先順位が低い場合でも、選択されていました。現在、優先順位がもっとも高い条件のハンドラが、ステートメントで最初に発生した条件でない場合でも、選択されるようになりました。

    詳細は、セクション13.6.7.6「ハンドラのスコープに関するルール」を参照してください。

  • データ型  次のデータ型の変更が実装されました。

    • MySQL では、マイクロ秒 (6 桁) までの精度を持つ TIMEDATETIME、および TIMESTAMP 値の小数秒に対応できるようになりました。セクション11.3.6「時間値での小数秒」を参照してください。

    • 以前には、テーブルごとに最大 1 つの TIMESTAMP カラムを自動的に初期化するか、現在の日時に更新することが可能でした。この制限は撤廃されました。どの TIMESTAMP カラム定義にも、DEFAULT CURRENT_TIMESTAMP 句と ON UPDATE CURRENT_TIMESTAMP 句の任意の組み合わせを指定できます。さらに、これらの句は、DATETIME カラム定義で使用できるようになりました。詳細は、セクション11.3.5「TIMESTAMP および DATETIME の自動初期化および更新機能」を参照してください。

    • MySQL では、TIMESTAMP データ型は、自動的な初期化および更新属性のデフォルト値と割り当ての点で、ほかのデータ型とは非標準的な方法で異なります。これらの動作はデフォルトのままですが、現在、非推奨になっており、サーバーの起動時に explicit_defaults_for_timestamp システム変数を有効にすることによってオフにすることができます。セクション11.3.5「TIMESTAMP および DATETIME の自動初期化および更新機能」およびセクション5.1.4「サーバーシステム変数」を参照してください。

  • ホストキャッシュ  MySQL では、クライアントがサーバーに接続するときに生じたエラーの原因に関する詳細が提供されるようになるとともに、クライアント IP アドレスとホスト名情報を含み DNS ルックアップを回避するために使用されるホストキャッシュへのアクセスが改善されました。次の変更が実装されました。

    • 新しい Connection_errors_xxx ステータス変数は、特定のクライアント IP アドレスに適用されない接続エラーに関する情報を提供します。

    • 特定の IP アドレスに適用されるエラーを追跡するために、ホストキャッシュにカウンタが追加され、新しい host_cache パフォーマンススキーマテーブルが、SELECT ステートメントを使用して調べられるようにホストキャッシュの内容を公開します。ホストキャッシュの内容にアクセスすると、どれだけの数のホストがキャッシュされているか、どのホストにどの種類の接続エラーが発生しているか、またはホストエラーカウントが max_connect_errors システム変数の上限にどれだけ近づいているかなどの質問に回答することができます。

    • ホストキャッシュサイズは、host_cache_size システム変数を使用して構成できるようになりました。

    詳細は、セクション8.11.5.2「DNS ルックアップの最適化とホストキャッシュ」およびセクション22.9.10.1「host_cache テーブル」を参照してください。

  • OpenGIS  OpenGIS 仕様は、2 つの幾何値の関係をテストする関数を定義します。MySQL は当初、オブジェクトバウンディング矩形を使用し、対応する MBR ベースの関数と同じ結果を返すように、これらの関数を実装しました。正確なオブジェクトの形状を使用する、対応するバージョンが利用できるようになりました。これらのバージョンの名前には ST_ プリフィクスが付けられています。たとえば、Contains() はオブジェクトバインディング矩形を使用しますが、ST_Contains() はオブジェクト形状を使用します。詳細は、セクション12.15.9「幾何オブジェクト間の空間関係をテストする関数」を参照してください。

非推奨になった機能

次の機能は、MySQL 5.6 で非推奨になり、今後のリリースで削除される可能性または予定があります。ほかのオプションがあれば、それを利用するためにアプリケーションを更新する必要があります。

  • ERROR_FOR_DIVISION_BY_ZERONO_ZERO_DATE、および NO_ZERO_IN_DATE の SQL モードは非推奨になり、これらのいずれかを含むように sql_mode 値を設定すると警告が生成されます。MySQL 5.7 では、これらのモードは何も行いません。代わりに、その効果は、厳密 SQL モード (STRICT_ALL_TABLES または STRICT_TRANS_TABLES) の効果に含まれます。MySQL 5.7 での変更の目的は、効果が厳密モードに依存した SQL モードの数を減らし、これらを厳密モード自体の一部にすることです。

    MySQL 5.7 へのアップグレードの高度な準備を行うには、SQL Mode Changes in MySQL 5.7を参照してください。その説明では、アプリケーションが MySQL 5.7 での SQL モードの変更によって影響されるかどうかを評価するためのガイドラインが示されます。

  • MySQL 5.6 における暗黙の GROUP BY ソートへの依存は、非推奨になっています。グループ化された結果の特定のソート順序を実現するには、明示的な ORDER BY 句を使用することをお勧めします。GROUP BY ソートは、たとえば、オプティマイザがもっとも効率的であると考えるどのような方法でも、グループ化を指示できるようにしたり、ソートオーバーヘッドを回避したりするためなどに、今後のリリースで変更される可能性のある MySQL 拡張機能です。

  • 4.1 以前のパスワードと mysql_old_password 認証プラグイン。MySQL 4.1 より前で使用される古いハッシュ形式で格納されているパスワードは、ネイティブのパスワードハッシュ方式を使用するパスワードよりもセキュアでないため、使用しないようにしてください。4.1 以前のパスワードと mysql_old_password 認証プラグインが非推奨になりました。4.1 より前のパスワードハッシュを持つアカウントを使用して接続することを防ぐために、secure_auth システム変数はデフォルトで有効になりました。(このようなパスワードハッシュを持つアカウントに対して接続を許可するには、--secure_auth=0 を使用してサーバーを起動してください。ただし、4.1 以前のパスワードは非推奨であるため、secure_auth を無効にすることも非推奨です。)

    データベース管理者は、mysql_old_password 認証プラグインを使用するアカウントを、代わりに mysql_native_password を使用するように変換することが推奨されます。アカウントのアップグレード手順については、セクション6.3.8.3「4.1 よりも前のパスワードハッシュ方式と mysql_old_password プラグインからの移行」を参照してください。

    OLD_PASSWORD() 関数は 4.1 以前のパスワードハッシュを生成しますが、これは、old_passwords システム変数が 1 に設定されている場合に PASSWORD() が行う処理と同じです。OLD_PASSWORD()old_passwords=1 は非推奨になっています。

  • --skip-innodb オプションとそのシノニム (--innodb=OFF--disable-innodb など)。

  • date_formatdatetime_format、および time_format システム変数 (これらは使用されていません)。

  • have_profilingprofiling、および profiling_history_size システム変数。

  • innodb_use_sys_malloc および innodb_additional_mem_pool_size システム変数。

  • timed_mutexes システム変数。これは何も行わず、何の効果もありません。

  • --language オプション。代わりに --lc-messages-dir オプションと --lc-messages オプションを使用してください。

  • ALTER TABLEIGNORE 句。ALTER IGNORE TABLE は、レプリケーションの問題を引き起こし、一意のインデックスの作成用のオンライン ALTER TABLE を妨げ、外部キーの問題 (親テーブルで削除された行) を引き起こします。

  • msql2mysqlmysql_convert_table_formatmysql_find_rowsmysql_fix_extensionsmysql_setpermissionmysql_waitpidmysql_zapmysqlaccess、および mysqlbug ユーティリティー。

  • mysqlhotcopy ユーティリティー。代替方法には、mysqldump と MySQL Enterprise Backup があります。

削除された機能

次の項目は廃止され、MySQL 5.6 で削除されました。ほかのオプションがあれば、それを利用するためにアプリケーションを更新する必要があります。

  • --log サーバーオプションと log システム変数。代わりに、一般クエリーログを有効にするには --general_log オプションを使用し、一般クエリーログファイル名を設定するには --general_log_file=file_name オプションを使用してください。

  • --log-slow-queries サーバーオプションと log_slow_queries システム変数。代わりに、スロークエリーログを有効にするには --slow_query_log オプションを使用し、スロークエリーログファイル名を設定するには --slow_query_log_file=file_name オプションを使用してください。

  • --one-thread サーバーオプション。代わりに --thread_handling=no-threads を使用してください。

  • --safe-mode サーバーオプション。

  • --skip-thread-priority サーバーオプション。

  • --table-cache サーバーオプション。代わりに table_open_cache システム変数を使用してください。

  • --init-rpl-role オプションと --rpl-recovery-rank オプション、rpl_recovery_rank システム変数、および Rpl_status ステータス変数。

  • engine_condition_pushdown システム変数。optimizer_switch 変数の engine_condition_pushdown フラグを代わりに使用します。

  • have_csvhave_innodbhave_ndbcluster、および have_partitioning システム変数。代わりに SHOW PLUGINS を使用するか、INFORMATION_SCHEMA データベースの PLUGINS テーブルをクエリーします。

  • sql_big_tables システム変数。代わりに big_tables を使用してください。

  • sql_low_priority_updates システム変数。代わりに low_priority_updates を使用してください。

  • sql_max_join_size システム変数。代わりに max_join_size を使用してください。

  • max_long_data_size システム変数。代わりに max_allowed_packet を使用してください。

  • FLUSH MASTER および FLUSH SLAVE ステートメント。代わりに RESET MASTER および RESET SLAVE ステートメントを使用してください。

  • SLAVE START および SLAVE STOP ステートメント。START SLAVE および STOP SLAVE ステートメントを使用してください。

  • SHOW AUTHORS および SHOW CONTRIBUTORS ステートメント。

  • SET ステートメントの OPTION および ONE_SHOT 修飾子。

  • DEFAULT をストアドプロシージャーまたはストアドファンクションのパラメータや、ストアドプログラムのローカル変数 (SET var_name = DEFAULT ステートメント) に割り当てることは、明示的に禁じられています。DEFAULT をシステム変数に割り当てることは、以前と同様に許可されています。

  • ほとんどの SHOW ENGINE INNODB MUTEX 出力は 5.6.14 で削除されます。SHOW ENGINE INNODB MUTEX 出力は、MySQL 5.7.2 で完全に削除されます。パフォーマンススキーマテーブル上にビューを作成することによって、比較可能な情報を生成できます。

1.5 MySQL の情報源

このセクションでは、MySQL メーリングリスト、ユーザーフォーラム、IRC (インターネットリレーチャット) など、役に立つと思われる情報を提供します。

1.5.1 MySQL メーリングリスト

このセクションでは MySQL メーリングリストの概要を説明するとともに、メーリングリストの使用ガイドラインを提供します。メーリングリストを購読すると、メーリングリストに投稿されたすべてのメッセージを電子メールとして受け取ることができます。自分の質問や回答をリストに送信することもできます。

このセクションに記載されているメーリングリストの購読を開始または購読を中止するには、http://lists.mysql.com/ にアクセスしてください。ほとんどは、個別のメッセージを得られる通常版、または毎日 1 つの大きなメッセージを受け取れるダイジェスト版から選択できます。

購読または購読中止に関するメッセージはいずれのメーリングリストにも送信しないでください。送信した場合、そのメッセージを購読する多くのユーザーへ自動的に配信されてしまいます。

あなたのローカルサイトには MySQL メーリングリストに登録した多くの購読者がいるかもしれません。その場合、ローカルなメーリングリストがあって、lists.mysql.com からサイトに送信されたメッセージはそのローカルリストに送信されるようになっている場合があります。その際は、ローカルの MySQL リストへの追加または削除については、あなたのシステム管理者にお問い合わせください。

メールプログラム内の個別のメールボックスにメーリングリストが送信されるようにするには、メッセージヘッダーから判別するようにフィルタを設定してください。List-ID: または Delivered-To: ヘッダーを使用して、リストのメッセージを識別することができます。

MySQL メーリングリストは次のとおりです。

  • announce

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

  • mysql

    MySQL の一般的な議論に使用される主要なリストです。議題によっては、より細分化されたメーリングリストで議論を行なった方がよい場合があります。適切でないリストに投稿すると、回答が得られないことがあります。

  • bugs

    MySQL の最新リリース以降に報告された問題を常に把握しておきたいユーザーや、バグの検出と修正の過程に積極的に参加したいユーザーのためのリストです。セクション1.6「質問またはバグをレポートする方法」を参照してください。

  • internals

    MySQL コードに携わる人を対象とするリストです。MySQL の開発に関する議論およびパッチ投稿を行うフォーラムでもあります。

  • mysqldoc

    MySQL のドキュメント化に携わる人を対象とするリストです。

  • benchmarks

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

  • packagers

    MySQL のパッケージングと配布に関する議論に関するリストです。これは、MySQL のパッケージングや、サポートするすべてのプラットフォームとオペレーティングシステム上でできるかぎり同じような MySQL の外観と操作性を確保することに関するアイデアを交換するため、配布管理者によって使用されるフォーラムです。

  • java

    MySQL Server と Java に関する議論に使用されます。ほとんどが、MySQL Connector/J などの JDBC ドライバに関する議論に使用されています。

  • win32

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

  • myodbc

    ODBC を使用した MySQL Server への接続に関するすべてのトピックに使用されます。

  • gui-tools

    MySQL のグラフィカルユーザーインタフェースツール、たとえば MySQL Workbench に関するすべてのトピックに使用されます。

  • cluster

    MySQL Cluster の議論に使用されます。

  • dotnet

    MySQL Server および .NET プラットフォームに関する議論に使用されます。ほとんどが MySQL Connector/Net に関連するものです。

  • plusplus

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

  • perl

    MySQL の DBD::mysql を使用した Perl サポートに関するすべてのトピックに使用されます。

質問に対する回答が MySQL のメーリングリストまたはフォーラムから得られなかった場合、Oracle から有料サポートを受ける方法があります。これにより、MySQL の開発者と連絡を直接とることができます。

次の MySQL メーリングリストは英語以外のものです。これらのリストは Oracle による運営ではありません。

  • フランス語のメーリングリスト。

  • 韓国語のメーリングリスト。購読するには、このメーリングリストに subscribe mysql your@email.address と書いた電子メールを送信してください。

  • ドイツ語のメーリングリスト。購読するには、このメーリングリストに subscribe mysql-de your@email.address と書いた電子メールを送信してください。このメーリングリストに関する詳細な情報は、http://www.4t2.com/mysql/ を参照してください。

  • ポルトガル語のメーリングリスト。購読するには、このメーリングリストに subscribe mysql-br your@email.address と書いた電子メールを送信してください。

  • スペイン語のメーリングリスト。購読するには、このメーリングリストに subscribe mysql your@email.address と書いた電子メールを送信してください。

1.5.1.1 メーリングリストを使用する際のガイドライン

HTML モードがオンになっているブラウザからメールメッセージを投稿しないでください。多くのユーザーはブラウザでメールを読みません。

メーリングリストの質問に回答するとき、多数のユーザーにとって興味深いと思われる回答は、質問した個人に直接返信する代わりにメーリングリストに投稿してもかまいません。その場合、元の投稿者以外のユーザーにも役立つように、包括的な回答をするようにしてください。メーリングリストに投稿する際には、回答が前の回答と重複していないことを確認してください。

回答で、質問の重要な部分を要約するように努めてください。元のメッセージ全体を引用する必要はありません。

回答がメーリングリストではなくあなた個人に送られた場合、問題を解決するのに役立った回答の恩恵をほかの人も受けられるように、回答を要約してメーリングリストに載せることは、よいエチケットとみなされます。

1.5.2 MySQL フォーラムにおける MySQL コミュニティーサポート

http://forums.mysql.com のフォーラムは重要なコミュニティーリソースです。多くのフォーラムに参加可能です。次のカテゴリがあります。

  • Migration (移行)

  • MySQL Usage (MySQL の使い方)

  • MySQL Connector

  • Programming Languages (プログラム言語)

  • Tools (ツール)

  • 3rd-Party Applications (サードパーティーによるアプリケーション)

  • Storage Engines (ストレージエンジン)

  • MySQL Technology (MySQL テクノロジ)

  • SQL Standards (SQL の標準化)

  • Business (ビジネス)

1.5.3 IRC (インターネットリレーチャット) の MySQL コミュニティーサポート

さまざまな MySQL メーリングリストやフォーラムに加え、IRC (インターネットリレーチャット) にも経験豊富なコミュニティーがあります。次は、当社が現在把握しているもっとも優れたネットワーク/チャネルです。

freenode (サーバーは http://www.freenode.net/ を参照してください。)

  • #mysql は MySQL に関する質問が中心ですが、ほかのデータベースや SQL に関する質問も受け付けています。MySQL と PHP、Perl、C 言語の組み合わせに関する質問も行われています。

  • #workbench は MySQL Workbench 関係の質問や考えが中心で、MySQL Workbench の開発者に出会うのに適した場所でもあります。

IRC ネットワークに接続するための IRC クライアントソフトウェアを探している場合は、xChat (http://www.xchat.org/) を参照してください。X-Chat (GPL ライセンス) Unix および Windows プラットフォームで使用できます (無料の Windows 版 X-Chat は http://www.silverex.org/download/ から入手できます)。

1.5.4 MySQL Enterprise

Oracle は、MySQL Enterprise のフォーラムで技術サポートを提供しています。ビジネスに不可欠な本番アプリケーションに MySQL DBMS を使用している組織の場合は、MySQL Enterprise は次を含む商用サブスクリプション製品です。

  • MySQL Enterprise Server

  • MySQL Enterprise Monitor

  • Monthly Rapid Update および Quarterly Service Pack

  • MySQL Knowledge Base

  • 24 時間 365 日の技術およびコンサルタントサポート

MySQL Enterprise は複数の層で利用可能で、ニーズにもっとも適したサービスのレベルを柔軟に選択できます。詳細については、MySQL Enterprise を参照してください。

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

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

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

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

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

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

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

  • http://lists.mysql.com/ で MySQL メーリングリストのアーカイブを検索します。セクション1.5.1「MySQL メーリングリスト」 を参照してください。

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

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

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

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

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

ほかのユーザーと問題について話し合う場合、MySQL メーリングリストのいずれかを使用することもできます。 セクション1.5.1「MySQL メーリングリスト」

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

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

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

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

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

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

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

Connector/ODBC (MyODBC) に関する問題がある場合、トレースファイルを生成し、レポートともに送信してください。How to Report Connector/ODBC Problems or Bugs を参照してください。

レポートに、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 がクラッシュしたあとでログを調べることでこの情報を取得できます。セクション24.4「MySQL のデバッグおよび移植」 を参照してください。

  • データベーステーブルが問題に関連している場合、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 ファイルを作成してください。targzip または zip を使用してファイルの圧縮アーカイブを作成します。http://bugs.mysql.com/ のバグデータベースのバグレポートを開始してから、バグレポートの「ファイル」タブをクリックして、アーカイブをバグデータベースにアップロードする指示に従ってください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.7 MySQL の標準への準拠

このセクションでは、MySQL と ANSI/ISO SQL 標準との関連について説明します。MySQL Server には SQL 標準に対する多数の拡張機能があり、ここでは、それらの拡張機能と使用方法について説明します。また、MySQL Server に不足している機能と、この不足分に対処する方法に関する情報も示します。

SQL 標準は 1986 年以降開発が繰り返され、複数のバージョンがあります。このマニュアルでは、SQL-92は 1992 年にリリースされた標準に、SQL:1999は 1999 年にリリースされた標準に、SQL:2003は 2003 年にリリースされた標準に、そしてSQL:2008は 2008 年にリリースされた最新バージョンの標準に対応しています。SQL 標準標準 SQLという語句は、常に SQL 標準の現バージョンを意味します。

製品に関する当社の主な目標の 1 つは、速度や信頼性を犠牲にすることなく、SQL 標準への準拠に向けた取り組みを続けることです。大部分のユーザーにとって MySQL Server が大幅に使いやすくなるのであれば、当社は SQL に対する拡張機能や SQL 以外の機能のサポートを積極的に追加します。HANDLER インタフェースがこの方針の一例です。セクション13.2.4「HANDLER 構文」を参照してください。

24 時間 365 日のミッションクリティカルな使用にも、負荷のかかる Web またはロギングの使用にも対応できるように、トランザクションデータベースと非トランザクションデータベースのサポートを継続しています。

MySQL Server は当初、小規模なコンピュータシステムで中規模のデータベース (1,000 万から 1 億行、または 1 テーブルあたり約 100M バイト) を操作できるように設計されました。現在の MySQL Server は、テラバイト規模のデータベースを処理しますが、ハンドヘルドデバイスや組み込みデバイスにより適した縮小バージョンでコードをコンパイルすることもできます。MySQL Server のコンパクトな設計によって、ソースツリーで競合することなく、これらのどちらの方向の開発も実現することができます。

現時点では、リアルタイムのサポートは予定されていませんが、MySQL のレプリケーション能力は重要な機能を実現します。

MySQL は ODBC レベル 0 から 3.51 をサポートします。

MySQL は、NDBCLUSTER ストレージエンジンを使用した高可用性データベースクラスタリングをサポートします。第18章「MySQL Cluster NDB 7.3 および MySQL Cluster NDB 7.4を参照してください。

ほとんどの W3C XPath 標準をサポートする XML 機能を実装しています。セクション12.11「XML 関数」を参照してください。

SQL モードの選択

MySQL Server は異なる SQL モードで動作でき、sql_mode システム変数の値に応じて異なるクライアントにこれらの異なるモードを適用できます。DBA はサイトサーバーの動作要件に一致するグローバル SQL モードを設定でき、各アプリケーションはアプリケーションのセッション SQL モードをアプリケーション独自の要件に設定できます。

モードは MySQL がサポートする SQL 構文と、MySQL が実行するデータ検証に影響します。これにより、MySQL をさまざまな環境で使用したり、MySQL をほかのデータベースサーバーと一緒に使用したりすることが、さらに容易になります。

SQL モードの設定の詳細は、セクション5.1.7「サーバー SQL モード」を参照してください。

ANSI モードでの MySQL の実行

ANSI モードで MySQL Server を実行するには、--ansi オプションを付けて mysqld を起動します。ANSI モードでのサーバーの実行は、次のオプションを指定してサーバーを起動する場合と同じです。

--transaction-isolation=SERIALIZABLE --sql-mode=ANSI

実行時に同じ効果を得るには、次の 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 モードでサーバーを実行した場合は、--ansi オプションがトランザクション分離レベルも設定するため、SQL モードを 'ANSI' に設定した場合とは少し異なります。

セクション5.1.3「サーバーコマンドオプション」を参照してください。

1.7.1 標準 SQL に対する MySQL 拡張機能

MySQL Server は、ほかの SQL DBMS にはない拡張機能をサポートします。それらを使用した場合、ほかの SQL サーバーにコードを移植できなくなるため注意してください。場合によっては、MySQL 拡張機能を含むコードを記述しても、次の形式のコメントを使用することで移植することができます。

この場合、MySQL Server は、ほかの SQL ステートメントのようにコメント内のコードを構文解析して実行しますが、ほかの SQL サーバーはその拡張機能を認識しません。たとえば、MySQL Server は次のステートメント内の STRAIGHT_JOIN キーワードを認識しますが、ほかのサーバーは認識しません。

SELECT col1 FROM table1,table2 WHERE ...

!文字のあとにバージョン番号を追加すると、コメント内の構文は、MySQL のバージョンが指定されたバージョン番号以上の場合にだけ実行されます。次のコメント内の TEMPORARY キーワードは MySQL 3.23.02 以降のサーバーでのみ実行されます。

CREATE TABLE t (a INT);

次の説明は、MySQL 拡張機能をカテゴリでまとめた一覧です。

  • ディスク上のデータの構成

    MySQL Server は、各データベースを MySQL データディレクトリ下のディレクトリにマップし、データベース内のテーブルをデータベースディレクトリ内のファイル名にマップします。これには、次のような意味があります。

    • ファイル名で大文字と小文字を区別するオペレーティングシステム (多くの Unix システムなど) 上の MySQL Server では、データベース名とテーブル名で大文字と小文字が区別されます。セクション9.2.2「識別子の大文字と小文字の区別」を参照してください。

    • 標準的なシステムコマンドを使用して、MyISAM ストレージエンジンで管理されるテーブルのバックアップ、名前変更、移動、削除、およびコピーを行うことができます。たとえば、MyISAM テーブルの名前変更を行うには、テーブルに対応する .MYD.MYI、および .frm ファイルの名前を変更します。(ただし、RENAME TABLEALTER TABLE ... RENAME を使用して、サーバーにファイル名を変更させることをお勧めします。)

  • 一般言語構文

    • デフォルトでは、'のほかに"でも文字列を囲むことができます。ANSI_QUOTES SQL モードが有効な場合、文字列を囲むことができるのは'だけであり、サーバーは"で囲まれた文字列を識別子と解釈します。

    • \は文字列内のエスケープ文字です。

    • SQL ステートメントでは、db_name.tbl_name 構文を使用して、さまざまなデータベースのテーブルにアクセスできます。同様の機能を備えた SQL サーバーもありますが、これは User space と呼ばれます。MySQL Server は、CREATE TABLE ralph.my_table ... IN my_tablespace など、ステートメントで使用されるようなテーブルスペースをサポートしません。

  • SQL ステートメント構文

    • ANALYZE TABLECHECK TABLEOPTIMIZE TABLE、および REPAIR TABLE ステートメント。

    • CREATE DATABASEDROP DATABASE、および ALTER DATABASE ステートメント。セクション13.1.10「CREATE DATABASE 構文」セクション13.1.21「DROP DATABASE 構文」、およびセクション13.1.1「ALTER DATABASE 構文」を参照してください。

    • DO ステートメント。

    • クエリーオプティマイザによるテーブルの処理方法に関する説明を取得する EXPLAIN SELECT

    • FLUSH および RESET ステートメント。

    • SET ステートメント。セクション13.7.4「SET 構文」を参照してください。

    • SHOW ステートメント。セクション13.7.5「SHOW 構文」を参照してください。MySQL 固有の SHOW ステートメントの多くによって生成される情報は、SELECT を使用して INFORMATION_SCHEMA をクエリーすることによって、より標準的な方法で取得できます。第21章「INFORMATION_SCHEMA テーブルを参照してください。

    • LOAD DATA INFILE の使用。多くの場合、この構文は Oracle の LOAD DATA INFILE と互換性があります。セクション13.2.6「LOAD DATA INFILE 構文」を参照してください。

    • RENAME TABLE の使用。セクション13.1.32「RENAME TABLE 構文」を参照してください。

    • DELETE + INSERT の代わりとしての REPLACE の使用。セクション13.2.8「REPLACE 構文」を参照してください。

    • ALTER TABLE ステートメントにおける CHANGE col_nameDROP col_name、あるいは DROP INDEXIGNORE または RENAME の使用。ALTER TABLE ステートメントにおける、複数の ADDALTERDROP、または CHANGE 句の使用。セクション13.1.7「ALTER TABLE 構文」を参照してください。

    • インデックス名の使用、カラムのプリフィクス上のインデックス、および CREATE TABLE ステートメントでの INDEX または KEY の使用。セクション13.1.17「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 句。

    • INSERTREPLACEDELETE、および UPDATE ステートメントの LOW_PRIORITY 句。

    • SELECT ステートメントにおける INTO OUTFILE または INTO DUMPFILE の使用。セクション13.2.9「SELECT 構文」を参照してください。

    • SELECT ステートメントにおける STRAIGHT_JOINSQL_SMALL_RESULT などのオプション。

    • GROUP BY 句で、選択したすべてのカラムの名前を列挙する必要はありません。これにより、ごく一部ではありますが、きわめて一般的なクエリーのパフォーマンスが向上します。セクション12.19「GROUP BY 句で使用される関数と修飾子」を参照してください。

    • ORDER BY を用いるだけでなく GROUP BY を用いても、ASC および DESC を指定できます。

    • := 割り当て演算子で、ステートメント内の変数を設定する機能。セクション9.4「ユーザー定義変数」を参照してください。

  • データ型

    • MEDIUMINTSET、および ENUM データ型と、さまざまな BLOB および TEXT データ型。

    • AUTO_INCREMENTBINARYNULLUNSIGNED、および ZEROFILL データ型の属性。

  • 関数と演算子

    • ほかの SQL 環境を使用していたユーザーにわかりやすいように、MySQL Server では多数の関数のエイリアスがサポートされています。たとえば、すべての文字列関数で、標準の SQL 構文と ODBC 構文の両方がサポートされています。

    • MySQL Server は、|| および && 演算子が、C プログラミング言語の場合と同様に論理 OR および AND を意味することを理解しています。MySQL Server では、||OR はシノニムであり、&&AND も同様です。この優れた構文のために、MySQL Server では、文字列の連結に標準 SQL の || 演算子を使用することができません。その代わりに、CONCAT() を使用します。CONCAT() は任意の数の引数を取るため、|| 演算子の使用を MySQL Server に変換することは簡単です。

    • value_list に複数の要素がある場合の、COUNT(DISTINCT value_list) の使用。

    • 文字列比較はデフォルトで、大文字と小文字が区別され、ソート順序は現在の文字セットの照合順序によって決定されます。デフォルトの文字セットは latin1 (cp1252 西ヨーロッパ) です。これ以外を希望する場合は、BINARY 属性で自身のカラムを宣言するか、BINARY キャストを使用する必要があります。これにより、辞書順ではなくベースとなる文字コード値を使用して比較が行われます。

    • % 演算子は MOD() のシノニムです。つまり、N % MMOD(N,M) と同等です。% は、C プログラマと、PostgreSQL との互換性のためにサポートされています。

    • SELECT ステートメントの出力カラムリスト (FROM の左側) の式で、=<><=<>=><<>><=>ANDOR、または LIKE 演算子を使用できます。例:

      mysql> SELECT col1=1 AND col2=2 FROM my_table;
    • LAST_INSERT_ID() 関数は、最新の AUTO_INCREMENT 値を返します。セクション12.14「情報関数」を参照してください。

    • LIKE は、数値に対して使用できます。

    • REGEXP および NOT REGEXP 拡張正規表現演算子。

    • 1 つまたは複数の引数を使用する CONCAT() または CHAR()。(MySQL Server では、これらの関数は引数をいくつでも使用することができます。)

    • BIT_COUNT()CASEELT()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()セクション12.19「GROUP BY 句で使用される関数と修飾子」を参照してください。

1.7.2 MySQL と標準 SQL との違い

MySQL Server を ANSI SQL 標準および ODBC SQL 標準に準拠したものにすることを目標としていますが、次のように、MySQL Server が異なる動作を示すことがあります。

  • MySQL と標準 SQL の権限システムには、いくつかの違いがあります。たとえば MySQL では、テーブルを削除しても、テーブルの権限が自動的に取り消されません。テーブルの権限を取り消すには、明示的に REVOKE ステートメントを発行する必要があります。詳細は、セクション13.7.1.6「REVOKE 構文」を参照してください。

  • CAST() 関数は、REAL または BIGINT に対するキャストをサポートしていません。セクション12.10「キャスト関数と演算子」を参照してください。

1.7.2.1 SELECT INTO TABLE の違い

MySQL Server では、Sybase SQL 拡張機能 SELECT ... INTO TABLE はまだサポートされていません。MySQL Server では代わりに、基本的に同じ処理を行う INSERT INTO ... SELECT 標準 SQL 構文がサポートされています。セクション13.2.5.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 を使用することもできます。

ユーザー定義変数で SELECT ... INTO を使用できます。カーソルとローカル変数を用いてストアドルーチン内でも同じ構文を使用できます。セクション13.2.9.1「SELECT ... INTO 構文」を参照してください。

1.7.2.2 UPDATE の違い

式で更新されるテーブルのカラムにアクセスする場合、UPDATE はそのカラムの現在の値を使用します。次のステートメントの 2 番目の割り当ては、col2 を元の col1 値ではなく、現在の (更新された) col1 値に設定します。この結果、col1col2 の値が同じになります。この動作は標準 SQL とは異なります。

UPDATE t1 SET col1 = col1 + 1, col2 = col1;

1.7.2.3 トランザクションおよびアトミック操作の違い

MySQL Server (バージョン 3.23-max およびすべてのバージョン 4.0 以降) では、InnoDB トランザクションストレージエンジンでトランザクションがサポートされています。MySQL 5.5 以上では、セクション14.1.1「デフォルトの MySQL ストレージエンジンとしての InnoDB」で説明しているように、新しく作成したテーブルではデフォルトで InnoDB が使用されます。デフォルトで、InnoDB完全な ACID コンプライアンスを提供します。ACID コンプライアンスと raw パフォーマンスとのバランスを取るように設定を調整する方法については、セクション14.2.1「MySQL および ACID モデル」を参照してください。トランザクションエラーの取り扱いにおける、標準 SQL と InnoDB との違いについては、セクション14.19.4「InnoDB のエラー処理」を参照してください。

MySQL Server での非トランザクションストレージエンジン (MyISAM など) は、アトミック操作と呼ばれるデータ整合性に関する別のパラダイムに従います。MyISAM テーブルは実質上常に、autocommit = 1 モードで操作します。変更されたデータは、一度に 1 つのステートメントでディスクに書き込まれるため、一連の関連する DML 操作は途中で妨害される可能性があり、この操作の一貫性を保証することが非常に困難になります。したがって、このモードは読み取りが大半のワークロードに適しています。トランザクションの条件では、それぞれの特定の更新が実行している間、ほかのユーザーがこれを妨げることができず、自動的なロールバックが存在できず、ダーティー読み取りが存在しません。ただし、これらの特性は単一の操作に適用され、一つの単位として成功または失敗する関連した更新には適用されません。LOCK TABLES ステートメントなどの回避策は、非トランザクションテーブルへの並列書き込みアクセスを制限します。

同じアプリケーション内の別々のテーブルの場合でも、どちらのパラダイムを使用するかを選択できます。信頼性と高いパフォーマンスを両立させる場合にはトランザクション機能を、(たとえばレプリケーションスレーブサーバーでの) 重要でない読み取りが大半のデータにはアトミック操作を選択できます。

InnoDB などのトランザクションストレージエンジンでは、負荷のかかる読み取り/書き込みワークロードに対する高い信頼性をサポートする多くの重要な機能が用意されています。結果として、トランザクションテーブルのメモリーおよびディスク容量の要件は高くなり、CPU オーバーヘッドが大きくなります。MySQL Server のモジュラー設計によって、さまざまなストレージエンジンの並列使用が可能になり、さまざまな要件に適合し、あらゆる状況で最適なパフォーマンスを実現できます。

非トランザクションテーブルでの信頼性に対する回避策

しかし、非トランザクションの MyISAM テーブルとの完全性も維持するには、MySQL Server の機能をどのように使用すればよいでしょうか。また、このような機能はトランザクションストレージエンジンにどのように匹敵するでしょうか。

  • 重大な状況で COMMIT ではなく ROLLBACK の呼び出しに依存するようにアプリケーションが作成されている場合、トランザクションの方が便利です。トランザクションでは、完了していない更新や失敗したアクティビティーがデータベースにコミットされていないことも確認します。サーバーには、自動ロールバックを行う機会が与えられ、データベースは保存されます。

    非トランザクションテーブルを使用する場合は、更新の前にチェックを含めることや、不整合についてデータベースをチェックし、このような不整合が発生した場合には自動的に修復または警告するスクリプトを実行することによって、アプリケーションレベルで潜在的な問題を解決する必要があります。MySQL ログを使用するか、さらに 1 つのログを追加することになっても、データの完全性を損なわずに、通常どおりテーブルを修正できます。

  • 場合によっては、重要なトランザクション更新は、アトミックになるように書き換えることができます。LOCK TABLES またはアトミック更新で複数の DML 操作を行うことができ、並列書き込みアクセスを制限することによってデッドロックが起こらないようにします。テーブルの末尾での並列挿入を可能にする、テーブルに対する READ LOCAL ロック (書き込みロックの反対) を取得した場合、読み取りは許可され、ほかのクライアントによる挿入も許可されます。新しく挿入したレコードは、読み取りがロックされているクライアントには、読み取りロックが解除されるまで表示されません。INSERT DELAYED を使用すると、ロックが解除されるまで挿入をローカルキューに入れることができ、クライアントは挿入が完了するまで待機する必要はありません。セクション8.10.3「同時挿入」およびセクション13.2.5.2「INSERT DELAYED 構文」を参照してください。

  • MySQL Server で安全性を確保するには、使用するテーブルの種類に関係なく、定期的にバックアップを作成してバイナリロギングをオンにします。使用するデータベースシステムに関係なく、どのような場合でもバックアップを作成することは賢明です。

次に、非トランザクションテーブルを操作するための手法を示します。

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

  • ROLLBACK を使用しないようにするため、次の方法を使用することができます。

    1. LOCK TABLES を使用して、アクセスするすべてのテーブルをロックします。

    2. 更新を実行する前に、true になっている必要がある条件をテストします。

    3. 条件が満たされていれば、更新します。

    4. UNLOCK TABLES を使用して、ロックを解除します。

    注記

    この解決方法は、だれかが更新の途中でスレッドを強制終了したときの状況に対処しません。その場合、すべてのロックが解除されますが、一部の更新が実行されていない可能性があります。

  • 次の手法を使用して、関数を用いて単一の操作でレコードを更新することもできます。

    • 現在の値に関連してカラムを変更します。これにより、別のクライアントがその間にカラム値を変更した場合でも、更新は正しくなります。

    • 実際に変更されたカラムのみを更新します。これが一般的にデータベースにとって適切な方法になります。

  • 一意の識別子を管理するときに、AUTO_INCREMENT カラムと、LAST_INSERT_ID() SQL 関数または mysql_insert_id() C API 関数のどちらかを使用することによって、LOCK TABLESROLLBACK などのステートメントを回避できます。セクション12.14「情報関数」およびセクション23.7.7.37「mysql_insert_id()」を参照してください。

    行レベルロックが必要な状況では、InnoDB テーブルを使用します。それ以外の場合、MyISAM テーブルでは、テーブルでフラグカラムを使用して、次のような操作を実行することができます。

    UPDATE tbl_name SET row_flag=1 WHERE id=ID;

    レコードが見つかり、元の行で row_flag がすでに 1 でなくなっていた場合、MySQL は、影響を受けた行の数として 1 を返します。MySQL Server が前述のステートメントを次のように変更したと考えることができます。

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

1.7.2.4 外部キーの違い

InnoDB ストレージエンジンは、CASCADEON DELETEON UPDATE などの外部キー制約のチェックをサポートします。セクション14.6.6「InnoDB と FOREIGN KEY 制約」を参照してください。

InnoDB および NDB 以外のストレージエンジンの場合、MySQL Server は CREATE TABLE ステートメントの FOREIGN KEY 構文を解析しますが、これを使用したり格納したりしません。この情報は、mysqldump にも存在し、Connector/ODBC を使用して取得できます。INFORMATION_SCHEMA 情報データベース内の INFORMATION_SCHEMA.TABLE_CONSTRAINTS テーブルをチェックすることによって、どのテーブルに外部キー制約があるかを確認できます。INFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTS テーブルから、外部キーに関する詳細を取得できます。さらに、InnoDB には、InnoDB テーブル上の外部キーに関する情報を含む多数の INFORMATION_SCHEMA テーブルが用意されています。セクション21.29「InnoDB の INFORMATION_SCHEMA テーブル」を参照してください。

データベース開発者にとって、次のような外部キーを使用するメリットがあります。

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

  • データベースサーバーによって集中的に制約チェックが行われるため、アプリケーション側でのこれらのチェックが不要になります。このことで、さまざまなアプリケーションで制約が同じようにチェックされない場合があるという可能性がなくなります。

  • 連鎖更新および削除を使用すると、アプリケーションコードを単純化することができます。

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

SQL の外部キーは、テーブルの結合ではなく、参照整合性のチェックと実施に使用されます。SELECT ステートメントで複数のテーブルからの結果を取得する場合は、次のようにそれらの結合を実行してください。

SELECT * FROM t1 INNER JOIN t2 ON t1.id = t2.id;

セクション13.2.9.2「JOIN 構文」およびセクション3.6.6「外部キーの使用」を参照してください。

ON DELETE ... を使用しない FOREIGN KEY 構文は、自動的に WHERE 句を作成するために、ODBC アプリケーションで使用されることがよくあります。

SQL 標準からの逸脱

MySQL での外部キーの実装は、次の重要な点で SQL 標準と異なります。

  • 同じ参照キー値を持つ複数の行が親テーブルにある場合、InnoDB は、同じキー値を持つほかの親の行が存在しないかのように、外部キーチェックで動作します。たとえば、RESTRICT 型の制約が定義されていて、複数の親の行を含む子の行が存在する場合は、これらの親の行のいずれかを削除することが InnoDB で許可されません。

    InnoDB では、外部キー制約に対応するインデックス内のレコードに基づいて、深さ優先アルゴリズムを使用したカスケード操作が実行されます。

  • UNIQUE でないキーを参照する FOREIGN KEY 制約は、標準 SQL ではなく InnoDB の拡張機能です。

  • ON UPDATE CASCADE または ON UPDATE SET NULL が同じカスケード中に以前に更新していた同じテーブルを更新するように再帰する場合、RESTRICT のように機能します。つまり、自己参照型 ON UPDATE CASCADE または ON UPDATE SET NULL 操作は使用できません。この目的は、カスケード更新で発生する無限ループを回避することです。反対に、自己参照型 ON DELETE SET NULL は、自己参照型 ON DELETE CASCADE と同様に動作できます。カスケード操作は、15 レベルよりも深くネストされる可能性がありません。

  • 多くの行を挿入、削除、または更新する SQL ステートメントでは、外部キー制約 (一意の制約など) が行ごとにチェックされます。外部キーチェックを行なっているとき、InnoDB は、調べる必要のある子レコードまたは親レコード上に共有行レベルロックを設定します。MySQL は外部キー制約の確認を即座に行います。その確認がトランザクションコミットまで遅延されることはありません。SQL 標準によると、デフォルトの動作は遅延チェックにするべきです。つまり、SQL ステートメント全体が処理されたあとにはじめて、制約がチェックされます。これは、外部キーを使用して自己参照する行を削除できないことを意味します。

InnoDB 外部キーが SQL 標準とどのように異なるかについては、セクション14.6.6「InnoDB と FOREIGN KEY 制約」を参照してください。

1.7.2.5 コメントの先頭としての「--」

標準 SQL では、コメントに C 構文 が使用され、MySQL Server でも同様にこの構文がサポートされています。セクション9.6「コメントの構文」で説明するように、MySQL は、MySQL 固有の SQL をコメントに埋め込めるようにする、この構文の拡張機能もサポートします。

標準 SQL では、-- をコメント開始連続文字として使用します。MySQL Server では、# をコメント開始文字として使用します。MySQL Server 3.23.3 以上では、-- コメントスタイルのバリアントもサポートします。つまり、-- コメント開始連続文字には空白 (または改行などの制御文字) を続ける必要があります。この空白は、payment の値を自動的に挿入する次のような構造構文を使用した自動生成の SQL クエリーでの問題を防止するために必要です。

UPDATE account SET credit=credit-payment

payment の値が負数 (-1など) の場合、どうなるかを考えてみてください。

UPDATE account SET credit=credit--1

credit--1 は SQL では有効な式ですが、-- はコメントの先頭として解釈され、式の一部は破棄されます。結果として、意図したものとはまったく異なる意味を持つステートメントとなってしまいます。

UPDATE account SET credit=credit

このステートメントでは、値が変更されることは一切ありません。これは、コメントを -- で開始できるようにすると、深刻な結果を招く可能性があること示します。

実装を使用するには、-- が MySQL Server 3.23.3 以降でのコメント開始連続文字として認識されるように、これに空白を続けることが必要になります。したがって、credit--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

セクション4.8.2「replace — 文字列置換ユーティリティー」を参照してください。

1.7.3 MySQL における制約の処理

MySQL では、ロールバックを許可するトランザクションテーブルと、許可しない非トランザクションテーブルの両方を操作できます。このため、MySQL とほかの DBMS とでは制約の処理が多少異なります。エラーが起きたときに変更をロールバックできない非トランザクションテーブルに、多数の行を挿入または更新した場合を扱う必要があります。

基本的な考え方は、MySQL Server が、実行するステートメントを構文解析している間に検出できるすべてのものに対してエラーを生成しようとし、ステートメントを実行する間に発生するエラーからリカバリしようとするというものです。ほとんどの場合でこれを行いますが、すべての場合にはまだです。

エラーが発生したときに MySQL で可能な選択肢は、途中でステートメントを中止するか、問題からリカバリするためにできるかぎりのことを行なって処理を続行するかです。デフォルトでは、サーバーは後者の方法に従います。これは、たとえば、サーバーは無効な値をもっとも近い有効な値に強制的に修正するということです。

不良データ値の処理や、エラー時にステートメント実行を継続するか中止するかをより適切に制御できるようにする複数の SQL モードオプションを利用できます。これらのオプションを使用して、不適切な入力を拒絶するほかの DBMS と同じように、より従来に近い方法で機能するように MySQL Server を構成できます。サーバー起動時に、SQL モードをグローバルに設定して、すべてのクライアントに影響を与えることができます。実行時に個々のクライアントで SQL モードを設定できるため、各クライアントは要件にもっとも適した動作を選択できます。セクション5.1.7「サーバー SQL モード」を参照してください。

次のセクションでは、さまざまな種類の制約を MySQL Server で処理する方法について説明します。

1.7.3.1 PRIMARY KEY および UNIQUE インデックス制約

通常、データ変更ステートメント (INSERTUPDATE など) がプライマリキー、一意キー、または外部キーの制約に違反すると、エラーが発生します。InnoDB などのトランザクションストレージエンジンを使用している場合、MySQL ではステートメントが自動的にロールバックされます。非トランザクションストレージエンジンを使用している場合、MySQL は、エラーが発生した行でステートメントの処理を停止し、残りの行を未処理のままにしておきます。

MySQL では、INSERTUPDATE などに対して IGNORE キーワードをサポートします。これを使用する場合は、MySQL は、プライマリキーまたは一意キーの違反を無視し、次の行を処理し続けます。使用しているステートメントに関するセクション (セクション13.2.5「INSERT 構文」セクション13.2.11「UPDATE 構文」など) を参照してください。

mysql_info() C API 関数で、実際に挿入または更新される行数についての情報を取得できます。SHOW WARNINGS ステートメントを使用することもできます。セクション23.7.7.35「mysql_info()」およびセクション13.7.5.41「SHOW WARNINGS 構文」を参照してください。

現時点では、外部キーがサポートされているのは InnoDB テーブルのみです。セクション14.6.6「InnoDB と FOREIGN KEY 制約」を参照してください。

1.7.3.2 FOREIGN KEY の制約

外部キーを使用すると、複数のテーブルにわたる関連データをクロス参照することができ、外部キー制約は、この分散したデータの整合性の維持に役立ちます。

MySQL は、CREATE TABLE および ALTER TABLE ステートメントにおける ON UPDATE および ON DELETE 外部キー参照をサポートします。使用可能な参照アクションは、RESTRICT (デフォルト)、CASCADESET NULL、および NO ACTION です。

注記

NDB は、参照カラムが親テーブルの主キーである ON UPDATE CASCADE アクションをサポートしません。

SET DEFAULT も MySQL Server でサポートされますが、現在、InnoDB および NDB によって無効として拒否されます。MySQL は遅延した制約のチェックをサポートしないので、NO ACTIONRESTRICT として扱われます。外部キーについて MySQL によってサポートされる正確な構文については、セクション13.1.17.2「外部キー制約の使用」を参照してください。

MATCH FULLMATCH PARTIAL、および MATCH SIMPLE は許可されますが、同じステートメントで使用されるすべて ON DELETE 句と ON UPDATE 句を MySQL Server に無視させるため、これらを使用しないでください。MySQL では MATCH オプションはほかの効果がなく、事実上常に MATCH SIMPLE セマンティクスが強制されます。

MySQL では、外部キーカラムにインデックスを付ける必要があります。外部キー制約はあるが所定のカラムのインデックスがないテーブルを作成する場合、インデックスが作成されます。例外: MySQL Cluster には、外部キーカラムで明示的な一意キー (または主キー) が必要です。

INFORMATION_SCHEMA.KEY_COLUMN_USAGE テーブルから、外部キーに関する情報を取得できます。このテーブルに対するクエリーの例を次に示します。

mysql> SELECT TABLE_SCHEMA, TABLE_NAME, COLUMN_NAME, CONSTRAINT_NAME > FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE > WHERE REFERENCED_TABLE_SCHEMA IS NOT NULL;+--------------+---------------+-------------+-----------------+
| TABLE_SCHEMA | TABLE_NAME | COLUMN_NAME | CONSTRAINT_NAME |
+--------------+---------------+-------------+-----------------+
| fk1 | myuser | myuser_id | f |
| fk1 | product_order | customer_id | f2 |
| fk1 | product_order | product_id | f1 |
+--------------+---------------+-------------+-----------------+
3 rows in set (0.01 sec)

InnoDB テーブル上での外部キーの情報は、INFORMATION_SCHEMA データベースにおける INNODB_SYS_FOREIGN および INNODB_SYS_FOREIGN_COLS テーブルにもあります。

1.7.3.3 無効データの制約

デフォルトでは、MySQL は無効または不適切なデータ値を許容しており、これらをデータエントリに対する有効な値に強制的に変更します。ただし、厳密 SQL モードを有効にして、サーバーが不良値を拒否し、不良値が発生するステートメントを中止するという従来の方法に近い不良値の取り扱いを選択できます。セクション5.1.7「サーバー SQL モード」を参照してください。

このセクションでは、MySQL のデフォルトの (許可されている) 動作のほか、厳密 SQL モードとこれがどのように異なるかについて説明します。

厳密モードを使用していない場合、NOT NULL カラムに NULL を挿入したり、数値カラムに大きすぎる数値を挿入したりするなど、正しくない値をカラムに挿入すると、MySQL は、エラーを生成するのではなく、カラムを最適可能値に設定します。この動作ルールについて、次に詳しく説明します。

  • 数値カラムに範囲外の値を格納しようとすると、MySQL Server は代わりに、0、指定可能な最小値、または指定可能な最大値 (いずれも無効値に近い値) を格納します。

  • 文字列については、MySQL は空白文字列、またはカラム内に格納可能な最長文字列を格納します。

  • 数字で始まらない文字列を数値カラムに格納しようとすると、MySQL Server は 0 を格納します。

  • セクション1.7.3.4「ENUM および SET の制約」で説明するように、ENUM カラムと SET カラムの無効な値は処理されます。

  • MySQL では、特定の不正なデータ値を、DATE カラムと DATETIME カラムに格納できます ('2000-02-31''2000-02-00' など)。この場合、アプリケーションが厳密 SQL モードを有効にしていなければ、これらを格納する前に日付を検証するのはアプリケーションに任されます。MySQL が日付値を格納し、ちょうど同じ値を検索できる場合、MySQL は与えられたとおりに格納します。日付が完全に不正な場合 (サーバーの格納能力を超えている場合) は、代わりに特殊なゼロ日付値である '0000-00-00' がカラムに格納されます。

  • NULL 値を使用することができないカラムに NULL を格納しようとすると、単一行の INSERT ステートメントに対するエラーが生じます。複数行の INSERT ステートメントや INSERT INTO ... SELECT ステートメントに対して、MySQL Server は、カラムデータ型に暗黙のデフォルト値を格納します。一般に、これは数値型には 0、文字列型には空の文字列 ('')、および日時型にはゼロ値になります。暗黙のデフォルト値については、セクション11.6「データ型デフォルト値」で説明されています。

  • 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 を有効にします。これは、STRICT_TRANS_TABLES と同じですが、非トランザクションストレージエンジンの場合に、2 行目以降の行の不良データであっても、エラーによりステートメントが中止する点が異なります。これは、非トランザクションテーブルで複数行の挿入または更新の途中でエラーが発生した場合、部分更新が行われることを意味します。これより前の行は挿入または更新されますが、エラーの時点以降の行は挿入も更新もされません。非トランザクションテーブルでこれを回避するには、単一行ステートメントを使用するか、エラーではなく変換警告が許容できる場合は STRICT_TRANS_TABLES を使用してください。初めから問題を避けるには、MySQL でカラム内容をチェックさせないようにしてください。データベースに有効な値だけを渡していることをアプリケーションに確認させることがもっとも安全です (多くの場合で高速になります)。

厳密モードオプションのいずれかで、IGNORE のない INSERT または UPDATE ではなく、INSERT IGNORE または UPDATE IGNORE を使用することによって、エラーを警告として処理することができます。

1.7.3.4 ENUM および SET の制約

ENUM および SET カラムによって、特定の値セットのみを含むカラムを効率的に定義することができます。セクション11.4.4「ENUM 型」およびセクション11.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 モードを使用するようにサーバーを構成できます。セクション5.1.7「サーバー SQL モード」を参照してください。厳密モードを有効にすると、ENUMSET カラムの定義は、カラムに入力した値に対して制約として機能します。これらの条件を満たさない値には、エラーが発生します。

  • 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' の値となります。

1.8 クレジット

次のセクションでは、MySQL を今日の形にするのを支援した開発者、貢献者、および支援者をリストします。

1.8.1 MySQL への貢献者

MySQL ServerMySQL マニュアルの全著作権はオラクル社およびその関連会社が保有しますが、MySQL ディストリビューションに何らかの形で貢献していただいた方々に感謝申し上げます。貢献者は、次のとおりです。順不同です。

  • Gianmassimo Vigazzola または

    Win32/NT への最初の移植。

  • Per Eric Olsson

    動的レコード形式に対する建設的な批評と実際のテスト。

  • Irena Pancirov

    Borland コンパイラを使用した Win32 の移植。mysqlshutdown.exe および mysqlwatch.exe

  • David J.Hughes

    シェアウェア SQL データベースの作成に尽力。MySQL AB の前身である TcX で、mSQL を始めましたが、それでは目的を達成できないことがわかったため、アプリケーションビルダー Unireg に対する SQL インタフェースの作成に転換しました。mysqladmin および mysql クライアントは、mSQL の対応するプログラムに大きな影響を受けています。MySQL 構文が mSQL のスーパーセットになるよう非常に努力しました。無料の mSQL プログラムを MySQL API に移植しやすくするため、API のアイデアの多くは mSQL に基づいたものです。MySQL ソフトウェアには、mSQL のコードは含まれません。ディストリビューションの 2 つのファイル (client/insert_test.c および client/select_test.c) は、mSQL ディストリビューションの対応する (著作権のない) ファイルに基づいていますが、例として、コードを mSQL から MySQL Server に変換するために必要な変更を示すために変更されています。(mSQL の著作権は David J.Hughes にあります。)

  • Patrick Lynch

    http://www.mysql.com/ の取得を支援。

  • Fred Lindberg

    MySQL メーリングリストを処理する qmail を設定し、MySQL メーリングリストの管理に関して多大な支援をいただいてます。

  • Igor Romanenko

    mysqldump (以前の msqldump ですが、Monty により移植および拡張されています)。

  • Yuri Dario

    MySQL OS/2 の移植の継続と拡張。

  • Tim Bunce

    mysqlhotcopy の作成者。

  • Zarko Mocnik

    スロベニア語のソート。

  • "TAMITO"

    _MB 文字セットのマクロと、ujis および sjis 文字セット。

  • Joshua Chamas

    同時挿入の基礎、拡張日付構文、NT でのデバッグ、および MySQL メーリングリストでの回答。

  • Yves Carlier

    ユーザーのアクセス権を表示するプログラム mysqlaccess

  • Rhys Jones (および GWE Technologies Limited)

    初期 JDBC ドライバの 1 つ。

  • Dr Xiaokun Kelvin ZHU

    初期 JDBC ドライバの 1 つと、ほかの MySQL 関連 Java ツールのさらなる開発。

  • James Cooper

    自分自身のサイトで検索可能なメーリングリストアーカイブのセットアップ。

  • Rick Mehalick

    MySQL Server のグラフィカルな X クライアントである xmysql

  • Doug Sisk

    Red Hat Linux 対応 MySQL の RPM パッケージの提供。

  • Diemand Alexander V.

    Red Hat Linux-Alpha 対応 MySQL の RPM パッケージの提供。

  • Antoni Pamies Olive

    Intel および SPARC 対応の多くの MySQL クライアントの RPM バージョンの提供。

  • Jay Bloodworth

    MySQL バージョン 3.21 対応 RPM バージョンの提供。

  • David Sacerdote

    DNS ホスト名のセキュアなチェックの方針。

  • Wei-Jou Chen

    中国語 (BIG5) キャラクタのサポート。

  • Wei He

    中国語 (GBK) 文字セット対応の多くの機能。

  • Jan Pazdziora

    チェコ語のソート順序。

  • Zeev Suraski

    FROM_UNIXTIME() の時間書式、ENCRYPT() 関数、および bison のアドバイザ。メーリングリストのアクティブなメンバー。

  • Luuk de Boer

    ベンチマークスイートを DBI/DBD に移植 (および拡張)。crash-me とベンチマークの実行の大きな助けとなりました。一部の新規日付関数。mysql_setpermission スクリプト。

  • Alexis Mikhailov

    ユーザー定義関数 (UDF)、CREATE FUNCTION および DROP FUNCTION

  • Andreas F.Bobak

    ユーザー定義関数の AGGREGATE 拡張。

  • Ross Wakelin

    MySQL-Win32 用 InstallShield の設定の支援。

  • Jethro Wright III

    libmysql.dll ライブラリ。

  • James Pereria

    MySQL Server を管理する Win32 GUI ツール Mysqlmanager。

  • Curt Sampson

    MIT-pthreads の NetBSD/Alpha および NetBSD 1.3/i386 への移植。

  • Martin Ramsch

    MySQL チュートリアル内のサンプル。

  • Steve Harvey

    mysqlaccess の安全性の改善。

  • Persistent Systems Private Limited の Konark IA-64 Centre

    MySQL Server の Win64 への移植の支援。

  • Albert Chin-A-Young.

    Tru64 用アップデートの構成、大きなファイルのサポート、優れた TCP ラッパーのサポート。

  • John Birrell

    OS/2 用 pthread_mutex() のエミュレーション。

  • Benjamin Pflugmann

    INSERTS を処理する拡張 MERGE テーブル。MySQL メーリングリストのアクティブなメンバー。

  • Jocelyn Fournier

    (特に MySQL 4.1 サブクエリーコードの) 無数のバグを発見しレポートしました。

  • Marc Liyanage

    OS X パッケージの保守および OS X パッケージの作成方法に関する非常に有益なフィードバックを提供。

  • Robert Rutherford

    QNX 移植に関する非常に有益な情報とフィードバックを提供。

  • NDB Cluster の以前の開発者

    夏期の学生、修士論文生、従業員など、多くの方がさまざまな方法で参加しました。合計で 100 名を超え、ここで全員の名前を挙げることができません。注目に値するのは、1999 年までコードベースの約 1/3 に貢献してきた Ataullah Dabaghi です。また、NDB Cluster のアーキテクチャーの基礎にブロック、信号、およびクラッシュ追跡機能を提供した AXE システムの開発者にも深く感謝いたします。1992 年から現在まで、開発に予算を割り当てるのに十分なアイデアであることを確信した方々も称賛に値します。

  • Google 社

    MySQL ディストリビューション、Mark Callaghan の SMP Performance パッチその他のパッチへの貢献で、Google 社に感謝いたします。

その他の貢献者、バグ発見者、およびテスター: James H.Thompson、Maurizio Menghini、Wojciech Tryc、Luca Berra、Zarko Mocnik、Wim Bonis、Elmar Haneke、、Ted Deppner 、Mike Simons、Jaakko Hyvatti。

メーリングリストのメンバーから提供された多くのバグレポートおよびパッチ。

MySQL メーリングリストの質問に回答いただいた方々に感謝いたします。

  • Daniel Koch

    Irix セットアップ。

  • Luuk de Boer

    ベンチマークの質問。

  • Tim Sailer

    DBD::mysql の質問。

  • Boyd Lynn Gerber

    SCO 関連の質問。

  • Richard Mehalick

    xmysql 関連の質問と基本的なインストールの質問。

  • Zeev Suraski

    Apache モジュール構成の質問 (ログおよび権限)、PHP 関連の質問、SQL 構文関係の質問およびその他の一般的な質問。

  • Francesc Guasch

    一般的な質問。

  • Jonathan J Smith

    Linux の OS 固有事項、SQL 構文、および何らかの作業を要するその他の事項に関する質問。

  • David Sklar

    PHP および Perl からの MySQL の使用。

  • Alistair MacDonald

    柔軟性があり、Linux およびおそらく HP-UX も操作できます。

  • John Lyon

    .rpm ファイルまたはソースからのコンパイルのいずれかによる、MySQL の Linux システムへのインストールに関する質問。

  • Lorvid Ltd.

    簡単な請求/ライセンス/サポート/著作権の問題。

  • Patrick Sherrill

    ODBC および VisualC++ インタフェースに関する質問。

  • Randy Harmon

    DBD、Linux、一部の SQL 構文に関する質問。

1.8.2 ドキュメント作成者および翻訳者

MySQL のドキュメント作成、およびドキュメントまたはエラーメッセージ翻訳にご協力いただいた方々を次に記載します。

  • Paul DuBois

    このマニュアルを正確でわかりやすいものにするために、継続してご協力いただいています。よく知られているように、Monty と David の英語ドキュメントのリライトも含まれます。

  • Kim Aldale

    Monty と David の初期の英語ドキュメントのリライト支援。

  • Michael J.Miller Jr.

    初回の MySQL マニュアルの作成。FAQ (ずいぶん前に MySQL マニュアルになりました) の多くのスペリングまたは言語の修正。

  • Yan Cailin

    2000 年初めに、Big5 および HK コード化バージョンが準拠している簡体字中国語に MySQL リファレンスマニュアルをはじめて翻訳。

  • Jay Flaherty

    マニュアル内の Perl DBI/DBD セクションの大部分に携わりました。

  • Paul Southworth , Ray Loyzaga

    リファレンスマニュアルの校正。

  • Therrien Gilbert 、Jean-Marc Pouyot

    フランス語のエラーメッセージ。

  • Petr Snajdr,

    チェコ語のエラーメッセージ。

  • Jaroslaw Lewandowski

    ポーランド語のエラーメッセージ。

  • Miguel Angel Fernandez Roiz

    スペイン語のエラーメッセージ。

  • Roy-Magne Mo

    ノルウェー語のエラーメッセージと MySQL 3.21.xx のテスト。

  • Timur I.Bakeyev

    ロシア語のエラーメッセージ。

  • & Filippo Grassilli

    イタリア語のエラーメッセージ。

  • Dirk Munzinger

    ドイツ語のエラーメッセージ。

  • Billik Stefan

    スロバキア語のエラーメッセージ。

  • Stefan Saroiu

    ルーマニア語のエラーメッセージ。

  • Peter Feher

    ハンガリー語のエラーメッセージ。

  • Roberto M.Serqueira

    ポルトガル語のエラーメッセージ。

  • Carsten H.Pedersen

    デンマーク語のエラーメッセージ。

  • Arjen Lentz

    オランダ語のエラーメッセージの以前の部分翻訳の完成 (一貫性とスペリングについてもチェック)。

1.8.3 MySQL をサポートするパッケージ

MySQL で多くのユーザーが使用するもっとも重要な API/パッケージ/アプリケーションの作成者/保守者のリストを次に記載します。

すべてのパッケージを記載すると保守が非常に困難になるため、すべてを記載することはできません。ほかのパッケージについては、http://solutions.mysql.com/software/ のソフトウェアポータルを参照してください。

  • Tim Bunce、Alligator Descartes

    DBD (Perl) インタフェース。

  • Andreas Koenig

    MySQL Server 用 Perl インタフェース。

  • Jochen Wiedmann

    Perl DBD::mysql モジュールの保守。

  • Eugene Chan

    MySQL Server 用 PHP の移植。

  • Georg Richter

    MySQL 4.1 のテストとバグ検出。MySQL 4.1 で使用するための新規 PHP 5.0 mysqli 拡張 (API)。

  • Giovanni Maruzzelli

    iODBC (Unix ODBC) の移植用。

  • Xavier Leroy

    LinuxThreads (Linux 上で MySQL Server が使用) の作成者。

1.8.4 MySQL の作成に使用されたツール

MySQL を作成するために使用したツールの一覧を次に示します。ここで、これらのツールを作成した方々に感謝申し上げます。これらのツールがなければ、MySQL は今日の形になりませんでした。

  • フリーソフトウェア財団 (Free Software Foundation)

    優れたコンパイラ (gcc)、優れたデバッガ (gdb)、および libc ライブラリを提供 (このライブラリの strto.c を使用して、Linux で動作するいくつかのコードを作成しました)。

  • フリーソフトウェア財団と XEmacs 開発チーム

    非常に優れたエディタ/環境を提供。

  • Julian Seward

    MySQL のバグ検出に役立った非常に優れたメモリーチェッカーツール valgrind の作成者。これがなければバグ検出は困難だったでしょう。

  • Dorothea Lütkehaus および Andreas Zeller

    gdb に対する優れたグラフィカルフロントエンドである DDD (データ表示デバッガ) を提供。

1.8.5 MySQL のサポータ

MySQL ServerMySQL マニュアル の全著作権はオラクル社およびその関連会社が保有しますが、新機能の開発に対する融資、MySQL Server の開発用のハードウェアの提供など、MySQL Server の開発を助成していただいた次の会社に感謝申し上げます。

  • VA Linux / Andover.net

    レプリケーションに対する資金提供。

  • NuSphere

    MySQL マニュアルの編集。

  • Stork Design studio

    1998 年 - 2000 年の MySQL Web サイト。

  • Intel

    Windows および Linux プラットフォーム上での開発に貢献。

  • Compaq

    Linux/Alpha 上での開発に貢献。

  • SWSoft

    埋め込み mysqld バージョンでの開発。

  • FutureQuest

    --skip-show-database オプション。

関連キーワード:  MySQL,1,および,してください,します,セクション,テーブル,ステートメント,SQL,Server