ALTER {DATABASE | SCHEMA} [db_name]
    alter_specification [alter_specification] ...

alter_specification:
    [DEFAULT] CHARACTER SET charset_name
  | [DEFAULT] COLLATE collation_name

ALTER DATABASE でデータベースの全体的な特徴を変更する事ができます。これらの特徴は、データベースディレクトリの db.opt ファイルに格納されています。ALTER DATABASE を利用する為には、データベース上の ALTER 権限が必要です。ALTER SCHEMA は ALTER DATABASE の同義語です。

CHARACTER SET 条項はデフォルト データベースの文字セットを変更します。COLLATE 条項はデフォルト データベースの照合を変更します。章?9. キャラクタセットサポートは文字セットと照合名を検討します。

ステートメントがデフォルト データベースに適応する場合、データベース名は省略する事ができます。

MySQL Enterprise 製造環境では、データベースの変更は頻繁に起こる事ではないので、セキュリティ違反を意味するかもしれません。MySQL ネットワーク モニタリングとアドバイス サービスの一環で提供されるアドバイザーが、データ定義ステートメントが発行されると、自動的に警告を発します。追加情報については http://www-jp.mysql.com/products/enterprise/advisors.html を参照してください。

ALTER [IGNORE] TABLE tbl_name
    alter_specification [, alter_specification] ...

alter_specification:
    table_option ...
  | ADD [COLUMN] column_definition [FIRST | AFTER col_name ]
  | ADD [COLUMN] (column_definition,...)
  | ADD {INDEX|KEY} [index_name] [index_type] (index_col_name,...)
  | ADD [CONSTRAINT [symbol]]
        PRIMARY KEY [index_type] (index_col_name,...)
  | ADD [CONSTRAINT [symbol]]
        UNIQUE [INDEX|KEY] [index_name] [index_type] (index_col_name,...)
  | ADD FULLTEXT [INDEX|KEY] [index_name] (index_col_name,...)
      [WITH PARSER parser_name]
  | ADD SPATIAL [INDEX|KEY] [index_name] (index_col_name,...)
  | ADD [CONSTRAINT [symbol]]
        FOREIGN KEY [index_name] (index_col_name,...)
        [reference_definition]
  | ALTER [COLUMN] col_name {SET DEFAULT literal | DROP DEFAULT}
  | CHANGE [COLUMN] old_col_name column_definition
        [FIRST|AFTER col_name]
  | MODIFY [COLUMN] column_definition [FIRST | AFTER col_name]
  | DROP [COLUMN] col_name
  | DROP PRIMARY KEY
  | DROP {INDEX|KEY} index_name
  | DROP FOREIGN KEY fk_symbol
  | DISABLE KEYS
  | ENABLE KEYS
  | RENAME [TO] new_tbl_name
  | ORDER BY col_name [, col_name] ...
  | CONVERT TO CHARACTER SET charset_name [COLLATE collation_name]
  | [DEFAULT] CHARACTER SET charset_name [COLLATE collation_name]
  | DISCARD TABLESPACE
  | IMPORT TABLESPACE
  | PARTITION BY partition_options
  | ADD PARTITION (partition_definition)
  | DROP PARTITION partition_names
  | COALESCE PARTITION number
  | REORGANIZE PARTITION partition_names INTO (partition_definitions)
  | ANALYZE PARTITION partition_names
  | CHECK PARTITION partition_names
  | OPTIMIZE PARTITION partition_names
  | REBUILD PARTITION partition_names
  | REPAIR PARTITION partition_names
  | REMOVE PARTITIONING

index_col_name:
    col_name [(length)] [ASC | DESC]

index_type:
    USING {BTREE | HASH}

ALTER TABLE で既存テーブルの構造を変更する事ができます。例えば、カラムの追加や削除、インデックスの作成や破壊、既存カラム タイプの変更、またはカラムやテーブル自体の名前の変更をする事ができます。テーブルや、テーブル タイプのコメントを変更する事もできます。

多くの許容される変更の構文は、CREATE TABLE ステートメントの条項に似ています。詳細については、項12.1.8. 「CREATE TABLE 構文」 をご参照ください。

ストレージ エンジンがその操作をサポートしていないテーブルに対しては、いくつかの操作の結果は警告になってしまうかもしれません。これらの警告は SHOW WARNINGS で表示する事ができます。詳しくは 項12.5.4.31. 「SHOW WARNINGS 構文」 を参照してください。

ほとんどの場合、 ALTER TABLE は元テーブルのテンポラリ コピーを作成する事で起動します。そのコピー上で変更が行われ、その後元テーブルが削除されて新しいテーブルがリネームされます。ALTER TABLE が実行している間、他のクライアントが元テーブルを読む事ができます。新しいテーブルの準備ができるまで更新と書き込みは止められ、その後更新に失敗する事なく新しいテーブルに自動的にリダイレクトされます。

テンポラリ テーブルが必要ない場合がいくつかあります。

そうでない場合は、そのデータが必ずコピーされる必要がある訳ではなくても、MySQL がテンポラリ テーブルを作成します。 (カラム名を変更した時と同じように)MyISAM テーブルは、高い値に myisam_sort_buffer_size システム変数を設定する事で、インデックスの再作成操作のスピードを上げる事ができます。 (これは変更プロセスの中で一番遅い操作です。)

mysql_info() C API 機能を利用すると、いくつの行がコピーされ、(IGNORE が利用された時) いくつの行がユニークキー値の複製の為に削除されたのかを確認する事ができます。詳しくは 項23.2.3.35. 「mysql_info()」 を参照してください。

ALTER TABLE の利用方法を表すいくつかの例があります。ここに表されているように作成された、テーブル t1 から始めましょう。

CREATE TABLE t1 (a INTEGER,b CHAR(10));

t1 から t2 のテーブルの名前を付けるには

ALTER TABLE t1 RENAME t2;

カラム a を INTEGER から TINYINT NOT NULL (同じ名前のまま)に変更する為に、そしてカラム b を、b から c に変更するのと同じように、CHAR(10) から CHAR(20) に変更する為には:

ALTER TABLE t2 MODIFY a TINYINT NOT NULL, CHANGE b c CHAR(20);

d と名づけられた新しい TIMESTAMP カラムを追加する為には:

ALTER TABLE t2 ADD d TIMESTAMP;

カラム d とカラム a にインデックスを追加する為には:

ALTER TABLE t2 ADD INDEX (d), ADD INDEX (a);

カラム c を取り除く為には:

ALTER TABLE t2 DROP COLUMN c;

c と名づけられた新しい AUTO_INCREMENT カラムを追加する為には:

ALTER TABLE t2 ADD c INT UNSIGNED NOT NULL AUTO_INCREMENT,
  ADD PRIMARY KEY (c);

AUTO_INCREMENT カラムはインデックスされなければいけない為、c (PRIMARY KEY として)をインデックスした、そして、主キー カラムは NULL になり得ない為 c を NOT NULL として宣言したという事を覚えておいて下さい。

AUTO_INCREMENT カラムを追加する時、カラム値はシーケンス番号で自動的にファイルされます。MyISAM テーブルには、ALTER TABLE の前に SET INSERT_ID=value を実行する事、またはAUTO_INCREMENT=value テーブルオプションを利用する事により最初のシーケンス番号を設定する事ができます。詳しくは 項12.5.3. 「SET 構文」 を参照してください。

MyISAM テーブルを利用すると、AUTO_INCREMENT カラムを変更しなければ、シーケンス番号は影響を受けません。もし AUTO_INCREMENT カラムをドロップし、そして別の AUTO_INCREMENT カラムを追加すると、番号は1から始まる順番に並べ直されます。

レプリケーションが利用された時、テーブルに AUTO_INCREMENT カラムを追加してもスレーブとマスターの行は同じ順番にはならないでしょう。これは、行の番号付けがテーブルに利用される特別なストレージ エンジンと、行が挿入される順番によって決まる為に起こります。もしマスターとスレーブ上で同じ順番である事が重要であれば、AUTO_INCREMENT 番号を割り当てる前に行の順番を整えておく必要があります。テーブル t1 に AUTO_INCREMENT カラムを追加したいと仮定して、次のステートメントは t1 と同一の AUTO_INCREMENT カラムを持つ新しいテーブル t2 を作成します。

CREATE TABLE t2 (id INT AUTO_INCREMENT PRIMARY KEY) 
SELECT * FROM t1 ORDER BY col1, col2;

これは、テーブル t1 はカラム col1 と col2 を持つと仮定します。

このステートメント セットはまた、t1 と同一の AUTO_INCREMENT カラムを追加した

新しいテーブル t2 を作成します。

CREATE TABLE t2 LIKE t1;
ALTER TABLE T2 ADD id INT AUTO_INCREMENT PRIMARY KEY;
INSERT INTO t2 SELECT * FROM t1 ORDER BY col1, col2;

重要:マスターとスレーブ上で同じ順番である事を保障する為に、t1 の全てのカラムは ORDER BY 条項内で参照を付けられる必要があります。

AUTO_INCREMENT カラムを持つコピーを作成、実装する為に利用した方法に関わらず、最後のステップは元テーブルをドロップし、コピーをリネームする事です。

DROP t1;
ALTER TABLE t2 RENAME t1;

項B.1.7.1. 「Problems with ALTER TABLE」 も参照してください。

ALTER LOGFILE GROUP logfile_group
    ADD UNDOFILE 'file'
    INITIAL_SIZE [=] size
    ENGINE [=] engine

このステートメントは、'file' と名付けられた UNDO ファイルを、既存ログファイルグループ logfile_group に追加します。ALTER LOGFILE GROUP ステートメントはたった一つの ADD UNDOFILE 条項を持ちます。DROP UNDOFILE 条項はサポートされていません。

INITIAL_SIZE パラメータは UNDO ファイルの冒頭のサイズをバイトで設定します。my.cnf で利用されている物と同様、大きさによって一文字の省略形を持つ size に従う事もできます。通常これは M (メガ バイト) か G (ギガ バイト)のどちらかの文字です。

ENGINE パラメータ(要求された)が、このログ ファイル グループによって利用されるストレージエンジンを決め、その名前はengine となります。MySQL 5.1では、engine に受け入れられる値は NDB と NDBCLUSTER だけです。

ここに、ログ ファイル グループ lg_3 が既に CREATE LOGFILE GROUP を利用して作成されていると仮定した例があります。(項12.1.9. 「CREATE LOGFILE GROUP 構文」 を参照してください。)

ALTER LOGFILE GROUP lg_3
    ADD UNDOFILE 'undo_10.dat'
    INITIAL_SIZE=32M
    ENGINE=NDB;

ALTER LOGFILE GROUP が ENGINE = NDB と共に利用された時、UNDO ログ ファイルがそれぞれのクラスタ データ ノード上に作成されます。INFORMATION_SCHEMA.FILES テーブルに問い合わせする事によって UNDO ファイルが作成され、それらの情報を得た事を証明する事ができます。例:

mysql> SELECT FILE_NAME, LOGFILE_GROUP_NUMBER, EXTRA 
    -> FROM INFORMATION_SCHEMA.FILES 
    -> WHERE LOGFILE_GROUP_NAME = 'lg_3';
+-------------+----------------------+----------------+
| FILE_NAME   | LOGFILE_GROUP_NUMBER | EXTRA          |
+-------------+----------------------+----------------+
| newdata.dat |                    0 | CLUSTER_NODE=3 |
| newdata.dat |                    0 | CLUSTER_NODE=4 |
| undo_10.dat |                   11 | CLUSTER_NODE=3 |
| undo_10.dat |                   11 | CLUSTER_NODE=4 |
+-------------+----------------------+----------------+
4 rows in set (0.01 sec)

(詳しくは 項21.21. 「INFORMATION_SCHEMA FILES テーブル」 を参照してください。)

MySQL 5.1.6 では ALTER LOGFILE GROUP が追加されました。MySQL 5.1 では MySQL クラスタのディスク データ ストレージと一緒の時のみ利用する事ができます。詳しくは 項14.11. 「MySQL Cluster ディスク データ ストレージ」 を参照してください。

ALTER TABLESPACE tablespace
    ADD DATAFILE 'file'
    INITIAL_SIZE [=] size
    ENGINE [=] engine

ALTER TABLESPACE tablespace
    DROP DATAFILE 'file'
    ENGINE [=] engine

このステートメントは新しいデータ ファイルを追加する時かテーブルスペースからデータ ファイルをドロップする時に利用する事ができます。

ADD DATAFILE 異形では、size がバイトで計算され、INITIAL_SIZE 構文を利用して初期のサイズを指定する事が要求されます。my.cnf で利用されている物と同様、大きさによって一文字の省略形を持つ整数値に従う事もできます。通常これは M (メガ バイト) か G (ギガ バイト)のどちらかの文字です。

一度データ ファイルが作成されると、そのサイズは変更できませんが、追加の ALTER TABLESPACE ... ADD DATAFILE ステートメントを利用する事によりテーブルスペースにより多くのデータ ファイルを追加する事ができます。

DROP DATAFILE を ALTER TABLESPACE と共に利用する事で、テーブルスペースから 'file' をドロップする事ができます。このファイルは CREATE TABLESPACE か ALTER TABLESPACE を利用してテーブルスペースに既に追加されていなければいけません。そうでなければエラーが発生します。

ALTER TABLESPACE ... ADD DATAFILE と ALTER TABLESPACE ... DROP DATAFILE の2つは、テーブルスペースに利用されるストレージ エンジンを指定する ENGINE 条項を必要とします。MySQL 5.1では、engine に受け入れられる値は NDB と NDBCLUSTER だけです。

ALTER TABLESPACE ... ADD DATAFILE が ENGINE = NDB と共に利用された時、データ ファイルがそれぞれのクラスタ データ ノード上に作成されます。INFORMATION_SCHEMA.FILES テーブルに問い合わせする事によってデータ ファイルが作成され、それらの情報を得た事を証明する事ができます。例えば、次のクエリは newts 名付けられたテーブルスペースに属する全てのデータ ファイルを表していす。

mysql> SELECT LOGFILE_GROUP_NAME, FILE_NAME, EXTRA 
    -> FROM INFORMATION_SCHEMA.FILES
    -> WHERE TABLESPACE_NAME = 'newts' AND FILE_TYPE = 'DATAFILE';
+--------------------+--------------+----------------+
| LOGFILE_GROUP_NAME | FILE_NAME    | EXTRA          |
+--------------------+--------------+----------------+
| lg_3               | newdata.dat  | CLUSTER_NODE=3 |
| lg_3               | newdata.dat  | CLUSTER_NODE=4 |
| lg_3               | newdata2.dat | CLUSTER_NODE=3 |
| lg_3               | newdata2.dat | CLUSTER_NODE=4 |
+--------------------+--------------+----------------+
2 rows in set (0.03 sec)

詳しくはこちらをを参照してください。項21.21. 「INFORMATION_SCHEMA FILES テーブル」

MySQL 5.1.6 では ALTER TABLESPACE が追加されました。MySQL 5.1 では MySQL クラスタの ディスク データ ストレージと一緒の時のみ利用する事ができます。詳しくは 項14.11. 「MySQL Cluster ディスク データ ストレージ」 を参照してください。

ALTER SERVER  server_name
OPTIONS (option ...)

server_name のサーバ情報を変更し、CREATE SERVER コマンドごとの指定オプションを調整します。詳しくは 項12.1.11. 「CREATE SERVER 構文」 を参照してください。mysql.servers テーブル内の対応するフィールドは適宜更新されます。

例えば、USER オプションを更新する為には:

ALTER SERVER s OPTIONS (USER 'sally');

ALTER SERVER を利用する為に特別な権限は必要ありません。

ALTER SERVER は自動コミットを引き起こしません。

CREATE {DATABASE | SCHEMA} [IF NOT EXISTS] db_name
    [create_specification [create_specification] ...]

create_specification:
    [DEFAULT] CHARACTER SET charset_name
  | [DEFAULT] COLLATE collation_name

CREATE DATABASE は、与えられた名前でデータベースを作成します。このステートメントを利用する為には、データベースに CREATE 権限が必要です。CREATE SCHEMA は CREATE DATABASE の同義語です。

もしデータベースが存在し、IF NOT EXISTS を指定しなかった場合、エラーが発生します。

create_specification オプションはデータベースの特徴を指定します。データベースの特徴は、データベース ディレクトリの db.opt ファイルに格納されています。CHARACTER SET 条項はデフォルト データベースの文字セットを指定します。COLLATE 条項はデフォルト データベースの照合を指定します。章?9. キャラクタセットサポートは文字セットと照合名を検討します。

MySQL 内のデータベースは、その中のテーブルに対応するディレクトリとして実行されます。最初にデータベースが作成された時にはその中にはテーブルが無いので、CREATE DATABASE ステートメントが、MySQL データディレクトリ下にディレクトリと db.opt ファイルだけを作成します。項8.2. 「識別子」 に許可されたデータベース名のルールが紹介されています。もしデータベース名が特別な文字を含んでいる場合、その名前は項8.2.3. 「ファイル名への識別子のマッピング」に表されているようにそれらの文字が暗号化された形を含んだ物になります。

もしデータ ディレクトリ下にディレクトリを手動で作成したら(例えば mkdirを利用して)、サーバはそれをデータベース ディレクトリとみなし、SHOW DATABASES のアウトプット内に現れます。

データベースを作成する為に mysqladmin プログラムを利用する事もできます。詳しくは 項7.9. 「mysqladmin ? MySQL サーバの管理を行うクライアント」 を参照してください。

CREATE [UNIQUE|FULLTEXT|SPATIAL] INDEX index_name
    [index_type]
    ON tbl_name (index_col_name,...)
    [index_option ...]

index_col_name:
    col_name [(length)] [ASC | DESC]

index_type:
    USING {BTREE | HASH}

index_option:
    KEY_BLOCK_SIZE value
  | index_type
  | WITH PARSER parser_name

CREATE INDEX は、インデックスを作成する為に ALTER TABLE ステートメントにマップされています。詳しくは 項12.1.2. 「ALTER TABLE 構文」 を参照してください。インデックスに関する更なる情報については、 項6.4.5. 「MySQLにおけるインデックスの使用」 を参照してください。

通常、テーブルが CREATE TABLE で作成される時にテーブル上に全てのインデックスを作成します。詳しくは 項12.1.8. 「CREATE TABLE 構文」 を参照してください。CREATE INDEX で既存テーブルにインデックスを追加する事ができます。

(col1,col2,...) のカラム リストは複合カラム インデックスを作成します。インデックス値は与えられたカラムの値を結合する事によって形作られます。

CHAR、VARCHAR、BINARY、そして VARBINARY カラムには、インデックス プリフィックス長を指定する為に col_name(length) 構文を利用して、カラム値の最初に部分だけを利用するインデックスを作成する事ができます。BLOB と TEXT カラムもまたインデックスする事ができますが、プリフィックス長を与える 必要があります。。プリフィックス長は非バイナリ文字列タイプには文字で指定され、バイナリ文字列タイプにはバイトで指定されます。これは、インデックス エントリはCHAR、VARCHAR、そして TEXT カラムのそれぞれのカラム値の最初の length 文字で、そして BINARY、 VARBINARY、そして BLOB カラムのそれぞれのカラム値の最初の length バイトで成り立っているという事です。

ここに表示されているステートメントは、 name カラムの最初の10文字を利用してインデックスを作成します。

CREATE INDEX part_of_name ON customer (name(10));

もしカラム内の名前の最初の10文字が違っていれば、このインデックスは name カラム全体から作成されたインデックスよりも遅くは無いはずです。また、部分的なカラムをインデックスに利用する事でインデックス　ファイルを小さくする事ができるので、ディスクのスペースを節約し、 INSERT 操作を早くする事ができます。

プリフィックスは最高で1000バイトの長さまで可能です。(InnoDB テーブルは767バイト)非バイナリ　データ　タイプ(CHAR、VARCHAR、TEXT)では CREATE INDEX ステートメントのプリフィックス長は文字数で解釈される一方、プリフィックス　リミットはバイトで計算されるという事を覚えておいて下さい。マルチバイトの文字セットを利用するカラムのプリフィックス長を指定する時にはこれを考慮に入れておいて下さい。

UNIQUE インデックスは、インデックス内の全ての値は明確でなければいけないというような制限を作成します。既存行とマッチするキー値の新しい行を追加しようとするとエラーが発生します。全てのエンジンに対して、UNIQUE インデックスは NULL を含む事ができるカラムの複数 NULL 値を許容します。

FULLTEXT インデックスは MyISAM テーブルにだけサポートされており、CHAR、VARCHAR、そして TEXT カラムだけを含む事ができます。インデックスする作業は必ずカラム全体に対して行われますので、部分的インデックスはサポートされておらず、プリフィックス長を指定しても無視されます。操作に関しての詳細は 項11.7. 「全文検索関数」 を参照してください。

SPATIAL インデックスは MyISAM テーブルに対してだけサポートされており、 NOT NULL として定義された空間カラムだけを含む事ができます。章?16. Spatial Extensionsで空間データタイプについて説明されています。

MySQL 5.1 内では

index_col_name 仕様は ASC か DESC で終わる事ができます。これらのキーワードは昇順や降順インデックス値ストレージを指定する為の将来の拡張子として許容されます。現在は、それらは解析されますが無視されます。インデックス値は毎回昇順で格納されます。

インデックス カラム リストに続き、インデックス オプションが与えられます。index_option 値は次のうちのどれかになり得ます。

CREATE [TEMPORARY] TABLE [IF NOT EXISTS] tbl_name
    (create_definition,...)
    [table_option ...]
    [partition_options]

または:

CREATE [TEMPORARY] TABLE [IF NOT EXISTS] tbl_name
    [(create_definition,...)]
    [table_option ...]
    [partition_options]
    select_statement

または:

CREATE [TEMPORARY] TABLE [IF NOT EXISTS] tbl_name
    { LIKE old_tbl_name | (LIKE old_tbl_name) }

create_definition:
    column_definition
  | [CONSTRAINT [symbol]] PRIMARY KEY [index_type] (index_col_name,...)
      [index_option ...]
  | {INDEX|KEY} [index_name] [index_type] (index_col_name,...)
      [index_option ...]
  | [CONSTRAINT [symbol]] UNIQUE [INDEX|KEY]
      [index_name] [index_type] (index_col_name,...)
      [index_option ...]
  | {FULLTEXT|SPATIAL} [INDEX|KEY] [index_name] (index_col_name,...)
      [index_option ...]
  | [CONSTRAINT [symbol]] FOREIGN KEY
      [index_name] (index_col_name,...) [reference_definition]
  | CHECK (expr)

column_definition:
    col_name data_type [NOT NULL | NULL] [DEFAULT default_value]
      [AUTO_INCREMENT] [UNIQUE [KEY] | [PRIMARY] KEY]
      [COMMENT 'string'] [reference_definition]

data_type:
    BIT[(length)]
  | TINYINT[(length)] [UNSIGNED] [ZEROFILL]
  | SMALLINT[(length)] [UNSIGNED] [ZEROFILL]
  | MEDIUMINT[(length)] [UNSIGNED] [ZEROFILL]
  | INT[(length)] [UNSIGNED] [ZEROFILL]
  | INTEGER[(length)] [UNSIGNED] [ZEROFILL]
  | BIGINT[(length)] [UNSIGNED] [ZEROFILL]
  | REAL[(length,decimals)] [UNSIGNED] [ZEROFILL]
  | DOUBLE[(length,decimals)] [UNSIGNED] [ZEROFILL]
  | FLOAT[(length,decimals)] [UNSIGNED] [ZEROFILL]
  | DECIMAL(length,decimals) [UNSIGNED] [ZEROFILL]
  | NUMERIC(length,decimals) [UNSIGNED] [ZEROFILL]
  | DATE
  | TIME
  | TIMESTAMP
  | DATETIME
  | YEAR
  | CHAR(length)
      [CHARACTER SET charset_name] [COLLATE collation_name]
  | VARCHAR(length)
      [CHARACTER SET charset_name] [COLLATE collation_name]
  | BINARY(length)
  | VARBINARY(length)
  | TINYBLOB
  | BLOB
  | MEDIUMBLOB
  | LONGBLOB
  | TINYTEXT [BINARY]
      [CHARACTER SET charset_name] [COLLATE collation_name]
  | TEXT [BINARY]
      [CHARACTER SET charset_name] [COLLATE collation_name]
  | MEDIUMTEXT [BINARY]
      [CHARACTER SET charset_name] [COLLATE collation_name]
  | LONGTEXT [BINARY]
      [CHARACTER SET charset_name] [COLLATE collation_name]
  | ENUM(value1,value2,value3,...)
      [CHARACTER SET charset_name] [COLLATE collation_name]
  | SET(value1,value2,value3,...)
      [CHARACTER SET charset_name] [COLLATE collation_name]
  | spatial_type

index_col_name:
    col_name [(length)] [ASC | DESC]

index_type:
    USING {BTREE | HASH}

index_option:
    KEY_BLOCK_SIZE value
  | index_type
  | WITH PARSER parser_name

reference_definition:
    REFERENCES tbl_name [(index_col_name,...)]
      [MATCH FULL | MATCH PARTIAL | MATCH SIMPLE]
      [ON DELETE reference_option]
      [ON UPDATE reference_option]

reference_option:
    RESTRICT | CASCADE | SET NULL | NO ACTION

table_option:
    [TABLESPACE tablespace_name STORAGE DISK]
    ENGINE [=] engine_name
  | AUTO_INCREMENT [=] value
  | AVG_ROW_LENGTH [=] value
  | [DEFAULT] CHARACTER SET charset_name
  | CHECKSUM [=] {0 | 1}
  | COLLATE collation_name
  | COMMENT [=] 'string'
  | CONNECTION [=] 'connect_string'
  | DATA DIRECTORY [=] 'absolute path to directory'
  | DELAY_KEY_WRITE [=] {0 | 1}
  | INDEX DIRECTORY [=] 'absolute path to directory'
  | INSERT_METHOD [=] { NO | FIRST | LAST }
  | KEY_BLOCK_SIZE [=] value
  | MAX_ROWS [=] value
  | MIN_ROWS [=] value
  | PACK_KEYS [=] {0 | 1 | DEFAULT}
  | PASSWORD [=] 'string'
  | ROW_FORMAT [=] {DEFAULT|DYNAMIC|FIXED|COMPRESSED|REDUNDANT|COMPACT}
  | UNION [=] (tbl_name[,tbl_name]...)

partition_options:
    PARTITION BY
          [LINEAR] HASH(expr)
        | [LINEAR] KEY(column_list)
        | RANGE(expr)
        | LIST(expr)
    [PARTITIONS num]
    [SUBPARTITION BY
          [LINEAR] HASH(expr)
        | [LINEAR] KEY(column_list)
      [SUBPARTITIONS num]
    ]
    [(partition_definition [, partition_definition] ...)]

partition_definition:
    PARTITION partition_name
        [VALUES {LESS THAN (expr) | MAXVALUE | IN (value_list)}]
        [[STORAGE] ENGINE [=] engine_name]
        [COMMENT [=] 'comment_text' ]
        [DATA DIRECTORY [=] 'data_dir']
        [INDEX DIRECTORY [=] 'index_dir']
        [MAX_ROWS [=] max_number_of_rows]
        [MIN_ROWS [=] min_number_of_rows]
        [TABLESPACE [=] (tablespace_name)]
        [NODEGROUP [=] node_group_id]
        [(subpartition_definition [, subpartition_definition] ...)]

subpartition_definition:
    SUBPARTITION logical_name
        [[STORAGE] ENGINE [=] engine_name]
        [COMMENT [=] 'comment_text' ]
        [DATA DIRECTORY [=] 'data_dir']
        [INDEX DIRECTORY [=] 'index_dir']
        [MAX_ROWS [=] max_number_of_rows]
        [MIN_ROWS [=] min_number_of_rows]
        [TABLESPACE [=] (tablespace_name)]
        [NODEGROUP [=] node_group_id]

select_statement:
    [IGNORE | REPLACE] [AS] SELECT ...   (Some legal select statement)

CREATE TABLE は、与えられた名前でデータ ベースを作成します。テーブルに対して CREATE 権限を持つ必要があります。

項8.2. 「識別子」 に許容テーブル名のルールが紹介されています。デフォルトによって、デフォルト データベースの中にテーブルが作成されます。テーブルが既に存在したり、デフォルト データベースが無かったり、データベースが存在しなかったりするとエラーが発生します。

指定データベース内にテーブルを作成するには、テーブル名を db_name.tbl_name と指定する事ができます。この作業は、デフォルト データベースが無くても、あると仮定して行われます。もし引用識別子を利用するなら、データベースとテーブル名は別々に引用してください。例えば、`mydb.mytbl` ではなく `mydb`.`mytbl` と書いてください。

テーブルを作成する時、TEMPORARY キーワードを利用する事ができます。TEMPORARY テーブルは現在の接続でのみ現れ、接続が終了すると自動的にドロップされます。これは、2つの異なる接続同士、または、既存の同名の非TEMPORARY テーブルとお互いに対立する事無く、同じテンポラリ テーブル名を利用する事ができるという意味になります。(テンポラリ テーブルがドロップされるまで、既存テーブルは隠されています。)テンポラリ テーブルを作成する為には CREATE TEMPORARY TABLES 特権を持つ必要があります。

注意:CREATE TABLE は、もし TEMPORARY キーワードを利用すると自動的に現在のアクティブなトランザクションを行いません。

もしテーブルが存在すると IF NOT EXISTS キーワードはエラーが起こるのを防ぎます。しかし、CREATE TABLE ステートメントに指示されたテーブルと既存テーブルが同一の構造である事の照合は行われません。注意:もし IF NOT EXISTS を CREATE TABLE ... SELECT ステートメント内で利用すると、SELECT 部分によって選択された全ての行はテーブルが既に存在するかどうかに関わらず挿入されます。

MySQL はそれぞれのテーブルをデータベース ディレクトリ内に .frm テーブル フォーマットで表します。テーブルのストレージ エンジンは別のファイルを作成する事もあります。MyISAM テーブルの場合、ストレージ エンジンはデータとインデックス ファイルを作成します。従って、各 MyISAM テーブル tbl_name は3つのディスク ファイルを持ちます。

章?13. ストレージエンジンとテーブルタイプ でテーブルを表す為にそれぞれのストレージ エンジンがどのファイルを作成するのか説明されています。もしテーブル名が特別な文字を含んでいる場合、そのテーブル ファイルの名前は項8.2.3. 「ファイル名への識別子のマッピング」に表されているようにそれらの文字が暗号化された形を含んだ物になります。

data_type は、データ タイプはカラム定義だという事を意味します。 spatial_type は空間データ タイプを意味します。表示されるデータ タイプ構文はただの見本です。各タイプの性質についての情報だけでなく、カラム データ タイプを指定する事ができる構文の完全な説明については、章?10. データタイプ と 章?16. Spatial Extensions を参照してください。

いくつかの属性は全てのデータ タイプには対応しません。AUTO_INCREMENT は整数タイプにのみ対応します。DEFAULT は BLOB や TEXT タイプには対応しません。

TABLESPACE ... STORAGE DISK テーブルオプションは NDB Cluster テーブルとのみ使用されます。これはテーブルをクラスタ ディスク データ テーブルスペースに割り当てます。tablespace_name と名づけられたテーブルスペースは CREATE TABLESPACE を利用してあらかじめ作成されている必要があります。このテーブルオプションは MySQL 5.1.6 で紹介されています。詳しくは項14.11. 「MySQL Cluster ディスク データ ストレージ」 を参照してください。

ENGINE テーブル オプションはテーブルにストレージ エンジンを指定します。

ENGINE テーブル オプションは、次のテーブルに表されているストレージ エンジン名を利用します。

もし適応しないストレージ エンジンが指定されると、MySQL は代わりにデフォルト エンジンを利用します。通常は MyISAM です。例えば、テーブル定義が ENGINE=INNODB オプションを含み、MySQL サーバが INNODB テーブルをサポートしなければ、そのテーブルは MyISAM テーブルとして作成されます。これは、トランザクショナル テーブルをマスタ上に持つが、スレーブ上に作成されたテーブルが非トランザクショナルである場合(スピードを速める為)の複製設定を可能にします。 MySQL 5.1 では、ストレージ エンジン仕様が支持されていなければ警告が表示されます。

注意:古い TYPE オプションは ENGINE と同義語です。MySQL 4.0 以降、TYPE は廃止されましたが、MySQL 5.1 (MySQL 5.1.7 となる予定)ではまだ後方互換性の為にサポートされています。MySQL 5.1.8 より、警告が表示されるようになりました。これはMySQL 5.2 では廃止される予定です。新しいアプリケーションの中では TYPE は利用するべきではありません、また、代わりに ENGINE を利用する為に、既存アプリケーションの変換を今すぐ始めるべきです。.（詳しくは 項C.1.9. 「Changes in release 5.1.8 (Not released)」 を参照してください。）

その他のテーブル オプションはテーブルの動作を最適化する為に利用されます。ほとんどの場合、それらのうちのどれも指定する必要はありません。これらのオプションは、指示されない限り全てのストレージ エンジンに適応します。与えられたストレージ エンジンに適応しないオプションは、受け入れられ、テーブル定義の一部として記憶されるでしょう。そのようなオプションは、後程もし異なるストレージ エンジンの利用の為にテーブルを変換する時 ALTER TABLE を利用すれば適応されます。

partition_options は CREATE TABLE を利用して作成されたテーブルの領域確保をコントロールする為に利用できます。重要:このセクションの冒頭で紹介された partition_options の構文内に表された全てのオプションが、全ての領域確保タイプに有効であるわけではありません。テーブル作成と MySQL 領域確保に関係する他のステートメントの追加例だけでなく、MySQL 内での領域確保の機能と使用に関しての完全な情報については、各タイプの情報仕様の為の個別タイプをリストした物、そして 章?15. パーティショニング を見てください。

partition_options は、もし利用されるなら最小の PARTITION BY 条項を含む必要があります。この条項はパーティションを決めるのに利用される関数を含んでいます。その関数は、num が分割数の時、1から num の整数値を返します。(1つのテーブルが含むユーザー定義パーティションの最高数は1024です。 このセクション ? の後半で紹介される ?サブ パーティションはこの最高数に含まれています。)MySQL 5.1 でこの機能に対して有効な物は次のリストに表されています。

各パーティションは partition_definition 条項を利用して個別に定義されるでしょう。この条項を形成するそれぞれの部分は次のような物です。

パーティションは修正し、マージし、テーブルに追加し、テーブルからドロップする事ができます。これらのタスクを成し遂げる為の基本的な MySQL ステートメントについての情報は、項12.1.2. 「ALTER TABLE 構文」 を参照してください。更なる詳細説明や例に関しては、項15.3. 「パーティショニング管理」 を参照してください。

CREATE TABLE ステートメントの最後に SELECT を追加する事で、1つのテーブルから別のテーブルを作成する事ができます。

CREATE TABLE new_tbl SELECT * FROM orig_tbl;

MySQLは SELECT 内の全ての要素に対して新しいカラムを作成します。例:

mysql> CREATE TABLE test (a INT NOT NULL AUTO_INCREMENT,
    ->        PRIMARY KEY (a), KEY(b))
    ->        ENGINE=MyISAM SELECT b,c FROM test2;

これは、これらの3つのカラム a、b、そして c を利用して MyISAM テーブルを作成します。SELECT ステートメントからのカラムは、テーブル上に重ねられるのではなくテーブルの右側に添付される事を覚えて置いてください。次の例を参考にして下さい。

mysql> SELECT * FROM foo;
+---+
| n |
+---+
| 1 |
+---+

mysql> CREATE TABLE bar (m INT) SELECT n FROM foo;
Query OK, 1 row affected (0.02 sec)
Records: 1  Duplicates: 0  Warnings: 0

mysql> SELECT * FROM bar;
+------+---+
| m    | n |
+------+---+
| NULL | 1 |
+------+---+
1 row in set (0.00 sec)

foo テーブル内のそれぞれの行には、foo からの値と新しいカラムのデフォルト値と共に bar に行が挿入されます。

CREATE TABLE ... SELECT の結果出来るテーブル内では、CREATE TABLE 部分の中でのみ名づけられたカラムが最初に来ます。両方で名づけられたカラムか SELECT 部分の中でのみ名づけられたカラムがその後に来ます。SELECT カラムのデータ タイプは CREATE TABLE 部分の中でカラムを指定する事によって無効にする事もできます。

もしデータをテーブルにコピーしている間にエラーが発生すると、それは自動的にドロップされるので作成されません。

CREATE TABLE ... SELECT は自動的にインデックスを作成しません。これはステートメントを可能な限りフレキシブルにする為に意図的に行われます。もし作成したテーブルの中でインデックスを持ちたければ、SELECT ステートメントの前にこれらを指定しなければいけません。

mysql> CREATE TABLE bar (UNIQUE (n)) SELECT n FROM foo;

データ タイプの変換が行われるかもしれません。例えば、AUTO_INCREMENT 属性は保管されず、VARCHAR カラムが CHAR カラムになる事ができます。

CREATE ... SELECT でテーブルを作成する時、必ずクエリの中では 全ての関数呼び出しや式をエイリアスにしてください。もしそれをしなければ、CREATE ステートメントは失敗するか、望まないカラム名になってしまいます。

CREATE TABLE artists_and_works
  SELECT artist.name, COUNT(work.artist_id) AS number_of_works
  FROM artist LEFT JOIN work ON artist.id = work.artist_id
  GROUP BY artist.id;

発生したカラムに対して、データ タイプを明示的に指定する事もできます。

CREATE TABLE foo (a TINYINT NOT NULL) SELECT b+1 AS a FROM bar;

元テーブルの中で指定されたカラム属性やインデックスを含む、他のテーブルの定義に基づき空のテーブルを作成するには、LIKE を利用してください。

CREATE TABLE new_tbl LIKE orig_tbl;

コピーは元テーブルと同じバージョンのテーブル ストレージ フォーマットを利用して作成されます。

CREATE TABLE ... LIKE は、元テーブルに対して、または外部キー定義に対して指示された DATA DIRECTORY や INDEX DIRECTORY テーブル オプションを保管しません。

ユニーク キー値を複製する行をどのように扱うかを指示する為に、IGNORE か REPLACE によって SELECT を先行させる事ができます。IGNORE 利用すると、ユニーク キー値上に既存の行を複製する新しい行は廃棄されます。REPLACE を利用すると、新しい行は同じユニーク キー値を持つ行を置き換えます。もし IGNORE も REPLACE も指示されなければ、複製ユニーク キー値はエラーになります。

バイナリ ログが元テーブルを再作成する為に利用できる事を保障する為に、MySQL は CREATE TABLE ... SELECT の最中の並列挿入を許可しません。

CREATE LOGFILE GROUP logfile_group
    ADD UNDOFILE 'undo_file'
    INITIAL_SIZE [=] initial_size
    [UNDO_BUFFER_SIZE [=] undo_buffer_size]
    ENGINE [=] engine_name

このステートメントは、'undo_file' と名づけられた単一 UNDO ファイルを持つ logfile_group という名前の新しいログ ファイル グループを作成する事ができます。CREATE LOGFILE GROUP ステートメントはたった一つの ADD UNDOFILE 条項を持ちます。

MySQL 5.1.8 から、いつでも1つのクラスタに付き1つだけのログ ファイル グループを持つ事ができるようになりました。（バグ #16386を参照して下さい。)

INITIAL_SIZE パラメータは UNDO ファイルの初期サイズを設定します。任意の UNDO_BUFFFER_SIZE パラメータは、ログ ファイル グループに対して UNDO バッファに利用されるサイズを設定します。UNDO_BUFFER_SIZE のデフォルト値は 8M (8メガバイト)で、この値は有効なシステム メモリの量を超える事はできません。initial_size と undo_buffer_size_size の両方はバイトで指示されます。my.cnf で利用されている物と同様、大きさによって一文字の省略形を持つこれらのうちのどちらか、または両方に従う事もできます。通常これは M (メガ バイト) か G (ギガ バイト)のどちらかの文字です。

ENGINE パラメータが、このログ ファイル グループによって利用されるストレージ エンジンを決め、その名前はengine となります。MySQL 5.1 では engine が NDB か NDBCLUSTER の値の1つにならなければいけません。

ENGINE = NDB と一緒に利用された時、ログ ファイル グループと、関連する UNDO ログ ファイルは、各クラスタ データ ノード上に作成されます。INFORMATION_SCHEMA.FILES テーブルに問い合わせする事によって UNDO ファイルが作成され、それらの情報を得た事を証明する事ができます。例:

mysql> SELECT LOGFILE_GROUP_NAME, LOGFILE_GROUP_NUMBER, EXTRA
    -> FROM INFORMATION_SCHEMA.FILES
    -> WHERE FILE_NAME = 'undo_10.dat';
+--------------------+----------------------+----------------+
| LOGFILE_GROUP_NAME | LOGFILE_GROUP_NUMBER | EXTRA          |
+--------------------+----------------------+----------------+
| lg_3               |                   11 | CLUSTER_NODE=3 |
| lg_3               |                   11 | CLUSTER_NODE=4 |
+--------------------+----------------------+----------------+
2 rows in set (0.06 sec)

(詳しくは 項21.21. 「INFORMATION_SCHEMA FILES テーブル」 を参照してください。)

MySQL 5.1.6 では CREATE LOGFILE GROUP が追加されました。MySQL 5.1 では MySQL クラスタの ディスク データ ストレージと一緒の時のみ利用する事ができます。詳しくは 項14.11. 「MySQL Cluster ディスク データ ストレージ」 を参照してください。

CREATE TABLESPACE tablespace
    ADD DATAFILE 'file'
    USE LOGFILE GROUP logfile_group
    [EXTENT_SIZE [=] extent_size]
    INITIAL_SIZE [=] initial_size
    ENGINE [=] engine

このステートメントは、テーブルに格納スペースを提供しながら1つ、または複数のデータ ファイルを含む事ができるテーブルスペースを作成する為に利用されます。1つのデータ ファイルはこのステートメントを利用してテーブルスペースに作成、または追加されます。ALTER TABLESPACE ステートメントを利用してテーブルスペースにデータ ファイルを追加する事ができます。(項12.1.4. 「ALTER TABLESPACE 構文」 を参照してください。)

1つ、または複数の UNDO ログ ファイルのログ ファイル グループは USE LOGFILE GROUP 条項を利用して作成する為にテーブルスペースに割り当てる必要があります。logfile_group は CREATE LOGFILE GROUP で作成した既存在ログ ファイル グループでなければいけません。(項12.1.9. 「CREATE LOGFILE GROUP 構文」 を参照してください。)複数のテーブルスペースは UNDO ロギングに同じログ ファイル グループを利用するでしょう。

EXTENT_SIZE は、テーブル スペースに属する全てのファイルに利用される範囲で、サイズをバイトで設定します。デフォルト値は4バイトです。

extent はディスク スペース割り当てのユニットです。1つの範囲は、別の範囲が利用されるまで、可能な限りのできるだけ多くのデータで満たされます。INFORMATION_SCHEMA.FILES テーブルをクエリする事によって、与えられたファイルでいくつの範囲がフリーであるかを確認する事ができるので、そのファイルの中でどれくらいのフリー スペースがあるのかの概算が導かれます。更なる情報や例に関しては、項21.21. 「INFORMATION_SCHEMA FILES テーブル」 を参照してください。

INITIAL_SIZE パラメータはデータ ファイルの合計サイズをバイトで設定します。一度データ ファイルが作成されると、そのサイズは変更できませんが、追加の ALTER TABLESPACE ... ADD DATAFILE を利用する事によりテーブルスペースにより多くのデータ ファイルを追加する事ができます。詳しくは 項12.1.4. 「ALTER TABLESPACE 構文」 を参照してください。

EXTENT_SIZE や INITIAL_SIZE を設定する時(片方、または両方)、my.cnf で利用されている物と同様、大きさによって一文字の省略形を持つ数字に従う事もできます。通常これは M (メガ バイト) か G (ギガ バイト)のどちらかの文字です。

ENGINE パラメータが、このテーブルスペースが利用するストレージ エンジンを決め、その名前はengine となります。MySQL 5.1 では engine が NDB か NDBCLUSTER の値の1つにならなければいけません。

CREATE TABLESPACE ... ADD DATAFILE が ENGINE = NDB と共に利用された時、テーブルスペースと関連するデータ ファイルがそれぞれのクラスタ データ ノード上に作成されます。INFORMATION_SCHEMA.FILES テーブルに問い合わせする事によってデータ ファイルが作成され、それらの情報を得た事を証明する事ができます。例:

mysql> SELECT LOGFILE_GROUP_NAME, FILE_NAME, EXTRA 
    -> FROM INFORMATION_SCHEMA.FILES
    -> WHERE TABLESPACE_NAME = 'newts' AND FILE_TYPE = 'DATAFILE';
+--------------------+-------------+----------------+
| LOGFILE_GROUP_NAME | FILE_NAME   | EXTRA          |
+--------------------+-------------+----------------+
| lg_3               | newdata.dat | CLUSTER_NODE=3 |
| lg_3               | newdata.dat | CLUSTER_NODE=4 |
+--------------------+-------------+----------------+
2 rows in set (0.01 sec)

(詳しくは 項21.21. 「INFORMATION_SCHEMA FILES テーブル」 を参照してください。)

MySQL 5.1.6 では CREATE TABLESPACE が追加されました。MySQL 5.1 では MySQL クラスタのディスク データ ストレージと一緒の時のみ利用する事ができます。詳しくは 項14.11. 「MySQL Cluster ディスク データ ストレージ」 を参照してください。

CREATE SERVER server_name
    FOREIGN DATA WRAPPER wrapper_name
    OPTIONS (option ...)

option:
  { HOST character-literal
  | DATABASE character-literal
  | USER character-literal
  | PASSWORD character-literal
  | SOCKET character-literal
  | OWNER character-literal
  | PORT numeric-literal }

このステートメントは FEDERATED ストレージ エンジンと共に利用する為のサーバの定義を作成します。CREATE SERVER ステートメントは mysql データベース内の servers テーブル内の新しい行を作成します。

server_name はサーバの固有の参照でなければいけません。サーバ定義は、サーバの領域内では広範囲です。特定のデータ ベースにサーバ定義を適応するのは不可能です。server_name は最長63文字の長さを持ち(63文字以上の名前は静かに切り捨てられる)、大文字と小文字を区別しません。単一引用句を利用して名前を指定します。

wrapper_name は mysql となる必要があり、そして1つの引用句を利用して引用されます。wrapper_name のその他の値は現在はサポートされていません。

各 option に対しては、文字直定数か数値定数のどちらかを指定しなければいけません。文字直定数は UTF 8で、最高64文字の長さとデフォルトを空の文字列にサポートします。文字列定数は静かに64文字まで切り捨てられます。数値定数は0から9999の間の数字である必要があり、デフォルト値は0です。

CREATE SERVER ステートメントを利用する為に特別な権限は必要ありません。

CREATE SERVER ステートメントは mysql.server テーブル内に FEDERATED テーブルを作成する時に CREATE TABLE ステートメントと共に利用する事ができるエントリを作成します。指定するオプションは mysql.server テーブル内にカラムを投入する為に利用されます。テーブルカラムは Server_name、Host、Db、Username、Password、Port そして Socket です。

例:

CREATE SERVER s
FOREIGN DATA WRAPPER mysql
OPTIONS (USER 'Remote', HOST '192.168.1.106', DATABASE 'test');

テーブルに格納されたデータは FEDERATED テーブルへの接続を作成する時に利用できます。

CREATE TABLE t (s1 INT) ENGINE=FEDERATED CONNECTION='s';

更なる情報については 項13.9. 「FEDERATED ストレージエンジン」 を参照してください。

CREATE SERVER は自動コミットを引き起こしません。

DROP {DATABASE | SCHEMA} [IF EXISTS] db_name

DROP DATABASE はデータベース内の全てのテーブルをドロップし、データベースを削除します。このステートメントには 十分 注意してください!DROP DATABASE を利用する為には、データベース上の DROP 権限が必要です。DROP SCHEMA は DROP DATABASE の同義語です。

重要:データベースがドロップされる時、データベース上のユーザ権限は自動的にドロップ されません 。詳しくは 項12.5.1.3. 「GRANT 構文」 を参照してください。

IF EXISTS は、データベースが存在しない時にエラーの発生を防ぎます。

もし象徴的にデータベースとリンクした DROP DATABASE を利用すると、リンクと元データベースの両方が削除されます。

DROP DATABASE は削除されたテーブル数を返します。これは、削除された .frm ファイルの数と対応しています。

DROP DATABASEステートメントは、通常作業の最中に MySQL が作成するファイルやディレクトリを与えられたデータベースから削除します。

MySQL がリストされたばかりのファイルやディレクトリを削除した後、もしデータベース ディレクトリ内に別のファイルやディレクトリが残れば、そのデータベース ディレクトリは削除する事ができません。この場合、残っている全てのファイルやディレクトリを手作業で削除し、DROP DATABASE ステートメントをもう一度発行しなければいけません。

mysqladmin でデータベースをドロップする事もできます。詳しくは 項7.9. 「mysqladmin ? MySQL サーバの管理を行うクライアント」 を参照してください。

DROP INDEX index_name ON tbl_name

DROP INDEX はテーブル tbl_name から index_name と名づけられたインデックスをドロップします。このステートメントは、インデックスをドロップする為に ALTER TABLE ステートメントにマップされます。詳しくは 項12.1.2. 「ALTER TABLE 構文」 を参照してください。

DROP [TEMPORARY] TABLE [IF EXISTS]
    tbl_name [, tbl_name] ...
    [RESTRICT | CASCADE]

DROP TABLE は1つまたは複数のテーブルを削除します。各テーブルごとに DROP　権限を持つ必要があります。全てのテーブル データとテーブル定義が 削除されます ので、このステートメントには 注意してください !引数リストの中に名前を付けたテーブルのいずれも存在しない場合、 MySQL は、存在していなかった為にドロップできなかったテーブルを名称別に表し、エラーを戻しますが、MySQL は既存リスト中のテーブルもすべてドロップします。

重要:テーブルがドロップされる時、テーブル上のユーザー権限は自動的にドロップ されません 。詳しくは 項12.5.1.3. 「GRANT 構文」 を参照してください。

パーティション テーブルに対しては、DROP TABLE がテーブル定義と、その全てのパーティションと、それらのパーティションに格納された全てのデータを恒久的に削除する事を覚えておいて下さい。これはまた、ドロップされたテーブルに関連する領域確保定義(.par)ファイルも削除します。

IF EXISTSを利用して、存在していないテーブルに対してエラーが発生するのを防いでください。IF EXISTSを使用すると、実在していないテーブルに対して NOTE が生成されます。詳しくは 項12.5.4.31. 「SHOW WARNINGS 構文」 を参照してください。

RESTRICT と CASCADE がポーティングを簡単にする事ができます。MySQL 5.1 ではそれらは何もしません。

注意:DROP TABLE は、TEMPORARY キーワードを利用しない限り自動的に現在のアクティブなトランザクションを行います。

TEMPORARY キーワードは次の効果を持ちます。

TEMPORARY を利用するのは、非 TEMPORARY テーブルを誤ってドロップしない事を保障するのに有効な方法です。

DROP LOGFILE GROUP logfile_group
    ENGINE [=] engine

このステートメントは logfile_group 名前が付いたログ ファイル グループをドロップします。ログ ファイル グループが既に存在していなければエラーが発生します。(ログ ファイル グループの作成についての詳細は 項12.1.9. 「CREATE LOGFILE GROUP 構文」 を参照してください。)

重要:ログ ファイル グループをドロップする前に、UNDO ロギングにそのログ ファイル グループを利用する全てのテーブルスペースをドロップしなければいけません。

必要とされる ENGINE 条項は、ドロップされるログ ファイル グループが利用するストレージ エンジン名を提供します。MySQL 5.1 では、engine に許可される値は NDB と NDBCLUSTER だけです。

MySQL 5.1.6 では DROP LOGFILE GROUP が追加されました。MySQL 5.1 では MySQL クラスタのディスク データ ストレージと一緒の時のみ利用する事ができます。詳しくは 項14.11. 「MySQL Cluster ディスク データ ストレージ」 を参照してください。

DROP TABLESPACE tablespace
    ENGINE [=] engine

このステートメントは CREATE TABLESPACE を利用して予め作成されたテーブルスペースをドロップします。(項12.1.10. 「CREATE TABLESPACE 構文」 を参照してください。）

重要:ドロップされるテーブルスペースはいかなるデータ ファイルも含む事はできません。言い換えると、テーブル スペースをドロップする前に、ALTER TABLESPACE ... DROP DATAFILE を利用してそれぞれのデータ ファイルをドロップしなければいけない、という事です。(項12.1.4. 「ALTER TABLESPACE 構文」 を参照してください。）

ENGINE 条項(要求された)はテーブルスペースに利用されるストレージ エンジンを指定します。MySQL 5.1では、engine に受け入れられる値は NDB と NDBCLUSTER だけです。

MySQL 5.1.6 では DROP TABLESPACE が追加されました。MySQL 5.1 では MySQL クラスタのディスク データ ストレージと一緒の時のみ利用する事ができます。詳しくは 項14.11. 「MySQL Cluster ディスク データ ストレージ」 を参照してください。

DROP SERVER [ IF EXISTS ] server_name

server_name と名づけられたサーバの、サーバ定義をドロップします。mysql.servers テーブル内の対応する行は削除されます。

テーブルの為にサーバをドロップする事は、作成時にこの接続情報を利用した FEDERATED テーブルに影響を与えません。詳しくは 項12.1.11. 「CREATE SERVER 構文」 を参照してください。

DROP SERVER を利用する為に特別な権限は必要ありません。

DROP SERVER は自動コミットを引き起こしません。

RENAME {DATABASE | SCHEMA} db_name TO new_db_name;

このステートメントはデータベースをリネームします。これは、データベースの ALTER と DROP 権限、そして新しいデータベースのCREATE 権限を必要とします。RENAME SCHEMA は RENAME DATABASE の同義語です。

サーバがこのステートメントを受け取る時、新しいデータベースを作成します。そしてそれは、テーブルと、トリガなどのようなその他のデータベース オブジェクトを新しいデータベースに移動します。それはまた、格納されたルーチンやイベントなどのようなオブジェクトのシステム テーブルに Db カラムを更新します。最後に、サーバは古いデータベースをドロップします。

現在はこれらの制限がありますので注意してください。

このステートメントは、MySQL 5.1.7 で追加されました。

RENAME TABLE tbl_name TO new_tbl_name
    [, tbl_name2 TO new_tbl_name2] ...

このステートメントは1つ、または複数のテーブルのリネームをします。

リネームは自動的に行われますので、その他のスレッドはリネーム作業中はどのテーブルにもアクセスできません。例えば、もし既存テーブル old_table があるとしたら、同じ構成で中身が空の別のテーブル new_table を作成し、その後、次のように既存テーブルと空のテーブルを入れ替える事ができます。(backup_table は存在していないと仮定する):

CREATE TABLE new_table (...);
RENAME TABLE old_table TO backup_table, new_table TO old_table;

もしこのステートメントが複数のテーブルをリネームすると、残りの作業は左から右に行われます。もし2つのテーブル名の入れ替えをしたければ、このように行う事ができます。(tmp_table が存在しないと仮定する):

RENAME TABLE old_table TO tmp_table,
             new_table TO old_table,
             tmp_table TO new_table;

2つのデータベースが同じファイル システム上にある限り、テーブルを1つのデータベースから別のものに移動するのに RENAME TABLE を利用する事ができます。

RENAME TABLE current_db.tbl_name TO other_db.tbl_name;

テーブルと関連し、RENAME TABLE を利用して別のデータベースに移動されたトリガがあると、ステートメントは Trigger in wrong schema というエラーになります。

RENAME TABLE はまた、別のデータベース内にビューをリネームしようとしなければ、ビューに対しても機能します。

リネームされたテーブルやビューに与えられた権限は、新しい名前に移動しません。それらは手動で変更しなければいけません。

RENAME を実行する時、ロックされたテーブルやアクティブなトランザクションを持つ事はできません。また、元テーブル上に ALTER と DROP 権限を、新しいテーブル上には CREATE と INSERT 権限を持つ必要があります。

もし MySQL が複合テーブルのリネームをしている最中にエラーが発生すると、全てを元に戻す為に全てのリネームされたテーブルにリバース リネームを行います。

単一テーブル構文:

DELETE [LOW_PRIORITY] [QUICK] [IGNORE] FROM tbl_name
    [WHERE where_condition]
    [ORDER BY ...]
    [LIMIT row_count]

複合テーブル構文:

DELETE [LOW_PRIORITY] [QUICK] [IGNORE]
    tbl_name[.*] [, tbl_name[.*]] ...
    FROM table_references
    [WHERE where_condition]

または:

DELETE [LOW_PRIORITY] [QUICK] [IGNORE]
    FROM tbl_name[.*] [, tbl_name[.*]] ...
    USING table_references
    [WHERE where_condition]

単一テーブル構文に対しては、DELETE ステートメントが tbl_name から行を削除し、削除された行数を返します。もし WHERE 条項が与えられたら、それはどの行を削除するべきかを決定します。WHERE 条項が無ければ、全ての行が削除されます。もし ORDER BY 条項が指定されると、指定された順に行が削除されます。LIMIT 条項は、削除できる行数に制限を設定します。

複合テーブル条項に対しては、DELETE はそれぞれの tbl_name から条件を満たしている行を削除します。この場合、ORDER BY と LIMIT を利用する事はできません。

where_condition は削除される各行に対して正しい結果の式です。それは 項12.2.7. 「SELECT 構文」 で述べられている通りに指定されます。

述べられているように、WHERE を持たない DELETE ステートメントは全ての行を削除します。削除された行数を知る必要がない場合にこの作業を速く行うには、TRUNCATE TABLE を利用してください。詳しくは 項12.2.9. 「TRUNCATE 構文」 を参照してください。

もし AUTO_INCREMENT カラムに対して最大値を持つ行を削除すると、その値は MyISAM か InnoDB テーブルに再度利用される事はありません。AUTOCOMMIT モードで DELETE FROM tbl_name を利用してテーブルの中の全ての行を削除すると(WHERE 条項なしで)、InnoDB と MyISAM 以外は全てのストレージ エンジンに対してシーケンスが始まります。項13.5.6.3. 「AUTO_INCREMENT カラムが InnoDB 内でどのように機能するか」 で紹介されているように、InnoDB テーブルに対するこの動作にはいくつか例外があります。

MyISAM テーブルには、複合カラム キー内の AUTO_INCREMENT セカンダリ カラムを指定する事ができます。この場合、MyISAM テーブルに対しても、シーケンスの先頭から削除された値の再利用が行われます。詳しくは Using AUTO_INCREMENT を参照してください。

DELETE ステートメントは次の修飾因子をサポートします。

削除操作のスピードは 項6.2.18. 「DELETEステートメントの速度」 で紹介されている要因によっても影響を受ける可能性があります。

MyISAM テーブルでは、削除された行はリンクされたリスト内で保存され、後続の INSERT 操作は古い行の位置を再利用します。利用されていないスペースを再利用しファイル サイズを縮小するには、テーブルを確認する為に OPTIMIZE TABLE ステートメントか myisamchk ユーティリティを利用してください。OPTIMIZE TABLE の方が簡単ですが、myisamchk の方が速いです。項12.5.2.5. 「OPTIMIZE TABLE 構文」、項7.4. 「myisamchk ? MyISAM テーブル メンテナンス ユーティリティ」 を参照して下さい。

QUICK 修飾因子は、インデックスが削除操作の為にマージされるかどうかに影響を与えます。DELETE QUICK は、削除された行のインデックス値が後で挿入された行に似ているインデックス値と置き換えられるアプリケーションに、最も有効です。この場合、削除された値によって作られた穴は再利用されます。

DELETE QUICK は、削除された値が、新しい挿入が再び行われるインデックス値の範囲にかかるアンダーフィルされたインデックスのブロックを導く場合には、有効ではありません。この場合、QUICK の利用は、未使用のままインデックス内に残る無駄なスペースを作り出します。ここに、同じようなシナリオの例があります。

このシナリオの中では、削除されたインデックス値に関連するインデックス ブロックはアンダーフィルされますが、QUICK を利用する事によって別のインデックス ブロックとマージされる事はありません。新しい行は削除された範囲内にインデックス値を持たないので、新しい挿入が行われてもそれらはアンダーフィルされたままです。その上、後で QUICK 無しで DELETE を利用しても、アンダーフィルされたブロック内またはその隣に、削除されたインデックス ブロックのいくつかが偶然残っていない限り、それらはアンダーフィルされたままです。このような条件下で、利用されていないインデックス スペースを再利用するには、OPTIMIZE TABLE を利用してください。

もしテーブルからたくさんの行を削除しようとしているのなら、OPTIMIZE TABLE が後に続く DELETE QUICK を利用する事で処理が速くできるかもしれません。これは、たくさんのインデックス ブロックのマージ操作を行うというよりは、インデックスを再構築する作業です。

MySQL 特有の、DELETE の為の LIMIT row_count オプションは、コントロールがクライアントに戻される前に、削除されるべき最大行数をサーバに伝えます。これは、与えられた DELETE ステートメントに時間がかかりすぎない事を保障します。影響される行数が LIMIT 値よりも少なくなるまで DELETE ステートメントを繰り返す事ができます。

もし DELETE ステートメントが ORDER BY 条項を含むなら、行は条項に指示された順番で削除されます。これは、LIMIT を持つ接続詞の中でだけ本当に役に立ちます。例えば、次のステートメントは WHERE 条項にマッチする行を見つけ、timestamp_column を利用してそれらをソートし、そして最初の（一番古い）物を削除します。

DELETE FROM somelog WHERE user = 'jcole'
ORDER BY timestamp_column LIMIT 1;

WHERE 条項内の特別な条件に依存する1つ、または複数のテーブルから行を削除する為に、DELETEステートメントの中で複数のテーブルを指定する事ができます。しかし、複合テーブル DELETE の中で ORDER BY や LIMIT を利用する事はできません。table_references 条項は接合箇所に含まれるテーブルをリストします。その構文は 項12.2.7.1. 「JOIN 構文」 で説明されています。

最初の複合テーブル構文には、FROM 条項の前にリストされた、テーブルのマッチする行だけが削除されます。2番目の複合テーブル構文では、FROM 条項(USING 条項の前) の前にリストされた、テーブルのマッチする行だけが削除されます。その効果は、複数のテーブルから同時に行を削除でき、検索の為だけに利用される追加テーブルを持つ事ができるという事です。

DELETE t1, t2 FROM t1, t2, t3 WHERE t1.id=t2.id AND t2.id=t3.id;

または:

DELETE FROM t1, t2 USING t1, t2, t3 WHERE t1.id=t2.id AND t2.id=t3.id;

これらのステートメントは、削除する行を検索する時に3つのテーブル全てを利用しますが、テーブル t1 と t2 からのマッチする行だけを削除します。

前出の例はカンマ演算子を利用する内部接合を表しますが、複合テーブルの DELETE ステートメントは、LEFT JOIN のような、SELECT ステートメント内で許容される接合タイプを利用する事ができます。

構文は Access を持つ互換性のテーブル名の後に .* を許容します。

外部キー制限があるテーブルに InnoDB テーブルを含む複合テーブル DELETE ステートメントを利用すると、MySQL のオプチマイザは、それらの親子関係の順番と違う順番でテーブルを処理するかもしれません。この場合、ステートメントは失敗し、ロールバックされます。代わりに、単一テーブルから削除し、他のテーブルが適宜修正されるように InnoDB が働きかける ON DELETE 性能に頼る必要があります。

注意:もしテーブルにエイリアスを付けるなら、そのテーブルを参照する時はそのエイリアスを利用しなければいけません。

DELETE t1 FROM test AS t1, test2 WHERE ...

データベース間をまたがる削除は、複合テーブル削除にサポートされていますが、この場合は、エイリアスを使わずにテーブルを参照する必要があります。例:

DELETE test1.tmp1, test2.tmp2 FROM test1.tmp1, test2.tmp2 WHERE ...

現在は、サブクエリの中で1つのテーブルから削除し、同じテーブルから選択する事はできません。

DO expr [, expr] ...

DO は式を実行しますが結果は返しません。あらゆる点で DO は SELECT expr, ... の省略表現ですが、結果を気にしない場合にはスピードが少し速いという利点があります。

DO は、RELEASE_LOCK() のような、副作用を持つ関数と共に利用すると効果的です。

HANDLER tbl_name OPEN [ AS alias ]
HANDLER tbl_name READ index_name { = | >= | <= | < } (value1,value2,...)
    [ WHERE where_condition ] [LIMIT ... ]
HANDLER tbl_name READ index_name { FIRST | NEXT | PREV | LAST }
    [ WHERE where_condition ] [LIMIT ... ]
HANDLER tbl_name READ { FIRST | NEXT }
    [ WHERE where_condition ] [LIMIT ... ]
HANDLER tbl_name CLOSE

HANDLER ステートメントは、テーブル ストレージ エンジン インターフェースへの直接アクセスを供給します。これは MyISAM と InnoDB テーブルに有効です。

HANDLER ... OPEN ステートメントはテーブルをオープンし、それに続く HANDLER ... READ ステートメントを通してテーブルをアクセス可能にします。このテーブルは他のスレッドと共有されず、スレッドが HANDLER ... CLOSE をコールするか、終了するまでは閉じられません。もしエイリアスを利用してテーブルをオープンすると、別の HANDLER ステートメントを利用しているオープンされたテーブルへの更なる参照時には、テーブル名ではなくエイリアスを利用しなければいけません。

最初の HANDLER ... READ 構文は、指定されたインデックスが与えられた値を満たし WHERE 条件が一致する行をフェッチします。もし複合カラム インデックスがあるなら、インデックス カラム値をカンマで区切られたリストで指示してください。インデックス内の全てのカラムに値を指定するか、インデックス カラムの左端のプリフィックスに値を指定してください。インデックス my_idx が col_a、col_b、そして col_c という名前の3つのカラムをこの通りの順番で含むと仮定してください。HANDLER ステートメントはインデックス内の3つ全てのカラム、または左端のプリフィックス内のカラムに値を指定する事ができます。例:

HANDLER ... READ my_idx = (col_a_val,col_b_val,col_c_val) ...
HANDLER ... READ my_idx = (col_a_val,col_b_val) ...
HANDLER ... READ my_idx = (col_a_val) ...

テーブルの PRIMARY KEY を参照する為に HANDLER インターフェースを利用するには、引用識別子の `PRIMARY` を利用してください。

HANDLER tbl_name READ `PRIMARY` ...

2つ目の HANDLER ... READ 構文は WHERE 条件に合うインデックス順でテーブルから行をフェッチします。

2つ目の HANDLER ... READ 構文は WHERE 条件に合うインデックス順でテーブルから行をフェッチします。これは、フル テーブル スキャンが必要な時には HANDLER tbl_name READ index_name よりも速いです。自然な行の順番というのは、MyISAM テーブル データ ファイルの中で行が格納されている順番です。このステートメントは InnoDB テーブルにも機能しますが、別のデータ ファイルがないので同じようなコンセプトはありません。

HANDLER ... READ の全ての形は単列が空いていれば LIMIT 無しでそれをフェッチします。指定した行数を返す為には LIMIT 条項を含んでください。これは、SELECT ステートメントと同じ構文を持ちます。詳しくは 項12.2.7. 「SELECT 構文」 を参照してください。

HANDLER ... CLOSE は HANDLER ... OPEN がオープンしたテーブルを閉じます。

HANDLER は若干低レベルなステートメントです。例えば、これは一貫性を持ちません。これは、HANDLER ... OPEN はテーブルのスナップショットを 撮らない、またテーブルを ロックしない という事です。これは、HANDLER ... OPEN ステートメントが発行された後、テーブル データを変更する事ができ（現在のスレッドか別のスレッドを利用して)、そしてそれらの変更点はHANDLER ... NEXT か HANDLER ... PREV スキャンで部分的にだけ見る事ができるかもしれない、という事を意味します。

通常の SELECT ステートメントの代わりに、HANDLER インターフェースを利用するのにはいくつかの理由があります。

INSERT [LOW_PRIORITY | DELAYED | HIGH_PRIORITY] [IGNORE]
    [INTO] tbl_name [(col_name,...)]
    VALUES ({expr | DEFAULT},...),(...),...
    [ ON DUPLICATE KEY UPDATE col_name=expr, ... ]

または:

INSERT [LOW_PRIORITY | DELAYED | HIGH_PRIORITY] [IGNORE]
    [INTO] tbl_name
    SET col_name={expr | DEFAULT}, ...
    [ ON DUPLICATE KEY UPDATE col_name=expr, ... ]

または:

INSERT [LOW_PRIORITY | HIGH_PRIORITY] [IGNORE]
    [INTO] tbl_name [(col_name,...)]
    SELECT ...
    [ ON DUPLICATE KEY UPDATE col_name=expr, ... ]

INSERT は既存テーブルに新しい行を挿入します。INSERT ... VALUES と INSERT ... SET 型のステートメントは、明示的に指定された値に基づいて行を挿入します。INSERT ... SELECT 型は別のテーブルから選択された行を挿入します。INSERT ... SELECT については 項12.2.4.1. 「INSERT ... SELECT 構文」 でさらに詳しく説明されています。

古い行に上書きする為に、INSERT の代わりに REPLACE を利用する事ができます。REPLACE は、古い行を複製する固有キー値を含む新しい行の取り扱いの中では INSERT IGNORE と同等になります。新しい行は捨てられるのではなく、古い行を置き換えるのに利用されます。詳しくは 項12.2.6. 「REPLACE 構文」 を参照してください。

tbl_name は行が挿入されるべきテーブルです。ステートメントが値を提供しなければいけないカラムは次のように指定する事ができます。

カラム値を与える方法はいくつかあります。

VALUES 構文を利用する INSERT ステートメントは複数行を挿入する事ができます。これをする為には、それぞれが括弧で囲まれカンマで区切られている、カラム値の複数リストを含んでください。例:

INSERT INTO tbl_name (a,b,c) VALUES(1,2,3),(4,5,6),(7,8,9);

各行の値のリストは括弧で囲まれている必要があります。次のステートメントは、カラム名の数とリストの中の値の数が合わない為、不正となります。

INSERT INTO tbl_name (a,b,c) VALUES(1,2,3,4,5,6,7,8,9);

INSERT の行に影響された値は mysql_affected_rows() C API 関数を利用して取得できます。詳しくは 項23.2.3.1. 「mysql_affected_rows()」 を参照してください。

もし INSERT ... VALUES ステートメントを複数値リストか INSERT ... SELECT と共に利用すると、そのステートメントはこのフォーマットで文字列情報を戻します。

Records: 100 Duplicates: 0 Warnings: 0

Records はステートメントによって生成された行数を指示します。(Duplicates がゼロ以外の数値になりえる為、実際に挿入された行数でなければいけないという訳ではありません。)既存の固有インデックス値を複製するので、Duplicates は挿入できなかった行数を指示します。Warnings は、何らかの形で問題があった、カラム値挿入の試みの回数を指示します。警告は次のような条件時に発生します。

もしC API を利用していれば、mysql_info() 関数を呼び出す事で、情報文字列を得ることができます。詳しくは 項23.2.3.35. 「mysql_info()」 を参照してください。

もし AUTO_INCREMENT カラムを持つテーブルに INSERT が行を挿入すれば、SQL LAST_INSERT_ID() 関数を利用する事でそのカラムに利用される値を見つける事ができます。C API の内部から、mysql_insert_id() 関数を利用してください。しかし、2つの関数がいつでも全く同じ働きをする訳ではない事に注意してください。AUTO_INCREMENT カラムに関しての、INSERT ステートメントの動作の更なる情報は 項11.10.3. 「情報関数」 と 項23.2.3.37. 「mysql_insert_id()」 で紹介されています。

INSERT ステートメントは次の修飾因子をサポートします。

INSERT [LOW_PRIORITY | HIGH_PRIORITY] [IGNORE]
    [INTO] tbl_name [(col_name,...)]
    SELECT ...
    [ ON DUPLICATE KEY UPDATE col_name=expr, ... ]

INSERT INTO tbl_temp2 (fld_id)
  SELECT tbl_temp1.fld_order_id
  FROM tbl_temp1 WHERE tbl_temp1.fld_order_id > 100;

INSERT DELAYED ...

INSERT INTO table (a,b,c) VALUES (1,2,3)
  ON DUPLICATE KEY UPDATE c=c+1;

UPDATE table SET c=c+1 WHERE a=1;

UPDATE table SET c=c+1 WHERE a=1 OR b=2 LIMIT 1;

INSERT INTO table (a,b,c) VALUES (1,2,3),(4,5,6)
  ON DUPLICATE KEY UPDATE c=VALUES(a)+VALUES(b);

INSERT INTO table (a,b,c) VALUES (1,2,3)
  ON DUPLICATE KEY UPDATE c=3;
INSERT INTO table (a,b,c) VALUES (4,5,6)
  ON DUPLICATE KEY UPDATE c=9;

INSERT INTO table (a,b,c) VALUES (1,2,3)
  ON DUPLICATE KEY UPDATE id=LAST_INSERT_ID(id), c=3;

LOAD DATA [LOW_PRIORITY | CONCURRENT] [LOCAL] INFILE 'file_name'
    [REPLACE | IGNORE]
    INTO TABLE tbl_name
    [FIELDS
        [TERMINATED BY 'string']
        [[OPTIONALLY] ENCLOSED BY 'char']
        [ESCAPED BY 'char']
    ]
    [LINES
        [STARTING BY 'string']
        [TERMINATED BY 'string']
    ]
    [IGNORE number LINES]
    [(col_name_or_user_var,...)]
    [SET col_name = expr,...]

LOAD DATA INFILE ステートメントは高スピードでテキスト ファイルからテーブルに行を読み込みます。ファイル名は直定数文字列として与えられなければいけません。

LOAD DATA INFILE は SELECT ... INTO OUTFILE の補数です。（詳しくは 項12.2.7. 「SELECT 構文」 をご確認ください。）テーブルからファイルにデータを書き込むには、SELECT ... INTO OUTFILE を利用してください。テーブルにファイルをリード バックするには、LOAD DATA INFILE を利用してください。両方のステートメントに対して FIELDS と LINES 条項の構文は同じです。条項は両方とも任意ですが、もし両方が指定された場合 FIELDS は LINES に先行しなければいけません。

INSERT 対 LOAD DATA INFILE の性能と、LOAD DATA INFILE のスピード アップの更なる情報については、項6.2.16. 「INSERTステートメントの速度」 を参照してください。

character_set_database システム変数によって指示された文字セットはかつてファイルの中の情報を解明していました。SET NAMES と character_set_client の設定はインプットの解明に影響を与えません。

現在は ucs2 文字セットを利用するデータ ファイルをロードするのは不可能だという事に気をつけてください。

MySQL 5.1.6 以降のバージョンでは、character_set_filesystem システム変数は、ファイル名の解明をコントロールします。

mysqlimport ユーティリティを利用する事でデータ ファイルをロードする事もできます。これは、サーバに LOAD DATA INFILE ステートメントを送信する事で機能します。--local オプションは mysqlimport がクライアント ホストからデータファイルを読み込むよう働きかけます。もしクライアントとサーバが圧縮されたプロトコルをサポートするなら、スピードが遅いネットワークにより良い性能を得る為に --compress オプションを指定する事ができます。詳しくは 項7.14. 「mysqlimport ? データインポートプログラム」 を参照してください。

もし LOW_PRIORITY を利用すると、別のクライアントがテーブルからの読み込みをしなくなるまで、LOAD DATA の実行が遅れます。

並列挿入の条件を満たす(フリーブロックが途中に無いという事) MyISAM テーブルと共に CONCURRENT を指定すると、LOAD DATA の実行中に他のスレッドがテーブルからデータを検索する事ができます。もし他のスレッドがテーブルを同時に利用していなくても、このオプションを利用する事は LOAD DATA の性能に少しだけ影響を与えます。

もし LOCAL キーワードが指定されたら、それは接続の最後にクライアントに関して解明されます。

これらのルールは、非 LOCAL の場合、 ./myfile.txt としてのファイル名はサーバーのデータ ディレクトリから読まれ、その一方、myfile.txt としてのファイル名はデフォルト データベースのデータベース ディレクトリから読み込まれるという事を意味しますので、注意してください。例えば、もし db1 がデフォルト データベースなら、ステーメントが db2 データベース内のテーブルにファイルを明示的にロードしたとしても、次の LOAD DATA ステートメントが db1 のデータベース ディレクトリからファイル data.txt を読み込みます。

LOAD DATA INFILE 'data.txt' INTO TABLE db2.my_table;

ウィンドウズのパス名は、バックスラッシュではなくフォーワードスラッシュで指定されます。もしバックスラッシュを利用すると、それらを2倍にする必要があります。

安全上の理由で、サーバ上にあるテキスト ファイルを読み込む時、ファイルはデータベース ディレクトリ上にあるか、全てによって読み込み可能である必要があります。また、 サーバ ファイル上で LOAD DATA INFILE を利用する時は、FILE 権限が必要です。詳しくは 項4.7.3. 「MySQL 提供の権限」 を参照してください。

LOCAL を利用すると、ファイルのコンテンツはクライアントからサーバに、その接続全体に送られなければいけないので、サーバがファイル ディレクトリにアクセスするのを許可するのよりも少し速度が遅くなります。反対に、ローカル ファイルをロードするのに FILE 特権は必要ありません。

LOCAL は、サーバとクライアントの両方が、これを許容できる場合のみ機能します。例えば、もし mysqld が --local-infile=0 と共に開始された場合、LOCAL は機能しません。詳しくは 項4.6.4. 「LOAD DATA LOCAL のセキュリティ関連事項」 を参照してください。

Unix上では、もしパイプから読み込む為に LOAD DATA が必要であれば、次のテクニックを利用する事ができます。(ここでは、テーブルの中に / ディレクトリのリストをロードします。)

mkfifo /mysql/db/x/x
chmod 666 /mysql/db/x/x
find / -ls > /mysql/db/x/x &
mysql -e "LOAD DATA INFILE 'x' INTO TABLE x" x

ロードされるデータを生成するコマンドと mysql を、別々のターミナルのどちらかで起動させる、または背景でデータ生成プロセスを起動させなければいけない (上記の例で表されているように)、という事に注意してください。もしこれを実行しないと、パイプはデータが mysql プロセスによって読み込まれるまでブロックします。

REPLACE と IGNORE キーワードは、固有のキー値上に既存行を複製するインプット行の扱いをコントロールします。

もしロード操作中に外部キー制約を無視したければ、LOAD DATA を実行する前に SET FOREIGN_KEY_CHECKS=0 ステートメントを発行する事ができます。

もし空の MyISAM テーブル上でLOAD DATA INFILE を利用すると、別のバッチに全ての非ユニーク インデックスが作成されます。(REPAIR TABLE に関して)通常この操作は、インデックスが多くある時に LOAD DATA INFILE のスピードを速くします。いくつかの極端な場合では、テーブルにファイルをロードする前に ALTER TABLE ... DISABLE KEYS を利用してインデックスをオフにしたり、ファイルをロードした後にインデックスを再作成する為に ALTER TABLE ... ENABLE KEYS を利用する事で、インデックスをさらに速く作成できます。詳しくは 項6.2.16. 「INSERTステートメントの速度」 を参照してください。

LOAD DATA INFILE と SELECT ... INTO OUTFILE ステートメントの両方に対して、FIELDS と LINES 条項の構文は同じです。条項は両方とも任意ですが、もし両方が指定された場合 FIELDS は LINES に先行しなければいけません。

もし FIELDS 条項を指定すると、少なくてもどれか1つを指定する必要はありますが、その各サブ条項 (TERMINATED BY、[OPTIONALLY] ENCLOSED BY、そして ESCAPED BY) もまた任意になります。

もし FIELDS 条項を指定しなければ、デフォルトは、このように書き込んだ場合と同じようになります。

FIELDS TERMINATED BY '\t' ENCLOSED BY '' ESCAPED BY '\\'

もし FIELDS 条項を指定しなければ、デフォルトは、このように書き込んだ場合と同じようになります。

LINES TERMINATED BY '\n' STARTING BY ''

言い換えると、インプットを読み込む時、デフォルトは LOAD DATA INFILE が次のように機能するよう働きかけるという事です。

反対に、デフォルトはアウトプットを書き込む時に SELECT ... INTO OUTFILE が次のように機能するよう働きかけます。

バックスラッシュは、MySQL の中では文字列内の拡張文字ですので、FIELDS ESCAPED BY '\\' を書き込むには、単一バックスラッシュだと認識させる為に2つのバックスラッシュを指定しなければいけません。

注意:もしウィンドウズ システム上でテキスト ファイルを生成したら、ウィンドウズのプログラムは通常ラインのターミネータとして2つの文字を利用するので、ファイルを正確に読み込む為には LINES TERMINATED BY '\r\n' を利用しなければいけないでしょう。WordPad のようないくつかのプログラムは、ファイルを書き込む時 \r をライン ターミネータとして利用するでしょう。そのようなファイルを読み込む時は、LINES TERMINATED BY '\r' を利用してください。

もし読み込みたいライン全てに、共通の無視したいプリフィックスがあれば、そのプリフィックスと、その前にある全ての物 を飛び越える為に LINES STARTING BY 'prefix_string' を利用する事ができます。もしラインがプリフィックスを持たなければ、ライン全体がスキップされます。このステートメントを発行すると仮定すると：

LOAD DATA INFILE '/tmp/test.txt' INTO TABLE test
  FIELDS TERMINATED BY ','  LINES STARTING BY 'xxx';

もしデータ ファイルがこのようになっていたら:

xxx"abc",1
something xxx"def",2
"ghi",3

行は結果として ("abc",1) と ("def",2) のようになります。ファイル内の3行目は、プリフィックスを含まないのでスキップされます。

IGNORE number LINES オプションはファイルの先頭のラインを無視する為に利用する事ができます。例えば、カラム名を含む冒頭のヘッダ ラインを飛び越える為に IGNORE 1 LINES を利用する事ができます。

LOAD DATA INFILE '/tmp/test.txt' INTO TABLE test IGNORE 1 LINES;

データベースからのデータをファイルに書き込み、その後そのファイルをデータベースに読み返す為に LOAD DATA INFILE と並行して SELECT ... INTO OUTFILE を利用する時、両方のステートメントの field- と line-handling オプションはマッチする必要があります。そうでなければ、LOAD DATA INFILE はファイルの内容を正確に解釈しません。カンマで区切られたフィールドを持つファイルを書き込む為に、SELECT ... INTO OUTFILE を利用すると仮定してください。

SELECT * INTO OUTFILE 'data.txt'
  FIELDS TERMINATED BY ','
  FROM table2;

カンマで区切られたファイルを読み返す為の正しいステートメントは次のようになります。

LOAD DATA INFILE 'data.txt' INTO TABLE table2
  FIELDS TERMINATED BY ',';

もし代わりに、次に表されているステートメントを利用してファイルを読み込もうとすると、LOAD DATA INFILE にフィールドの間にあるタブを探すよう指示を出すので、そのステートメントは機能しません。

LOAD DATA INFILE 'data.txt' INTO TABLE table2
  FIELDS TERMINATED BY '\t';

各インプット ラインが単一フィールドとして解釈されるという結果がよく出されます。

LOAD DATA INFILE は、外部ソースから得たファイルを読見込むのに利用する事ができます。例えば、多くのプログラムは、ラインがカンマで区切られたフィールドを持ち、2つの引用句で囲まれている というような、カンマで区切られた値（CSV）のフォーマットでデータをエクスポートする事ができます。もしそのようなファイルの中のラインが改行で終了していたら、ここに表されているステートメントはファイルをロードする為に利用するであろう field- と line-handling オプションを説明します。

LOAD DATA INFILE 'data.txt' INTO TABLE tbl_name
  FIELDS TERMINATED BY ',' ENCLOSED BY '"'
  LINES TERMINATED BY '\n';

field- または line-handling オプションは空の文字列を指定する事ができます。 ('')もし空でなければ、FIELDS [OPTIONALLY] ENCLOSED BY と FIELDS ESCAPED BY 値は単一文字という事になります。FIELDS TERMINATED BY、LINES STARTING BY、そして LINES TERMINATED BY 値は一文字以上になり得ます。例えば、キャリッジ リターンと改行のペアで終わっているラインを書いたり、そのようなラインを含むファイルを読み込む為には、 LINES TERMINATED BY '\r\n' 条項を指定してください。

%% で成り立つラインによって区切られているジョークを含むファイルを読み込むには、これを実行する事ができます。

CREATE TABLE jokes
  (a INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
  joke TEXT NOT NULL);
LOAD DATA INFILE '/tmp/jokes.txt' INTO TABLE jokes
  FIELDS TERMINATED BY ''
  LINES TERMINATED BY '\n%%\n' (joke);

FIELDS [OPTIONALLY] ENCLOSED BY はフィールドの引用句をコントロールします。アウトプットには(SELECT ... INTO OUTFILE)、もし OPTIONALLY を省略すると全てのフィールドが ENCLOSED BY 文字によって囲まれます。そのようなアウトプット(フィールド デリミタとしてカンマを利用している)の例がここに表されています。

"1","a string","100.20"
"2","a string containing a , comma","102.20"
"3","a string containing a \" quote","102.20"
"4","a string containing a \", quote and comma","102.20"

もし OPTIONALLY を指定すると ENCLOSED BY 文字は (CHAR、BINARY、TEXT、または ENUM のような) 文字列データタイプを持つカラムからの値を囲む為だけに利用されます。

1,"a string",100.20
2,"a string containing a , comma",102.20
3,"a string containing a \" quote",102.20
4,"a string containing a \", quote and comma",102.20

フィールド値内の ENCLOSED BY 文字の発生は、ESCAPED BY 文字と共にそれらをプリフィックスする事で拡張する事ができるという事を覚えておいて下さい。また、もし空の ESCAPED BY 値を指定すると、LOAD DATA INFILE で正しく読み込む事ができないアウトプットを気づかずに生成してしまう可能性がある事も覚えておいて下さい。例えば、もし拡張文字が空なら、表示されただけの先行するアウトプットは次のように現れます。4つ目のラインの2つ目のフィールドの引用句の後に、フィールドを(誤って)終了させるカンマが含まれている事を確認してください。

1,"a string",100.20
2,"a string containing a , comma",102.20
3,"a string containing a " quote",102.20
4,"a string containing a ", quote and comma",102.20

インプットに関しては、もし ENCLOSED BY 文字があれば、フィールド値の最後から剥ぎ取られます。(OPTIONALLY が指定されているかどうかは関係なくこれは事実です。OPTIONALLY はインプットの解釈に対して影響しません。)ESCAPED BY 文字に先行された ENCLOSED BY 文字の発生は、現在のフィールド値の一部として解釈されます。

もしフィールドが ENCLOSED BY 文字で始まると、その文字のインスタンスはフィールド、またはライン TERMINATED BY シーケンスが後に続いている場合のみ、そのフィールド値を終了させていると判断されます。曖昧さを防ぐ為に、フィールド値内の ENCLOSED BY 文字の発生を2倍にすると、その文字の単一インスタントとして解釈されます。例えば、もし ENCLOSED BY '"' が指定されると、引用句はここに表されているように扱われます。

"The ""BIG"" boss"  -> The "BIG" boss
The "BIG" boss      -> The "BIG" boss
The ""BIG"" boss    -> The ""BIG"" boss

FIELDS ESCAPED BY は、特別な文字をどのように書き込み、読み込むのかをコントロールします。もし FIELDS ESCAPED BY 文字が空でなければ、それはアウトプット上に次の文字をプリフィックスする為に利用されます。

もし FIELDS ESCAPED BY 文字が空なら、文字が拡張される事はなく、NULL は \N ではなく NULL としてアウトプットされます。特に、もしデータ中のにフィールド値が先ほどのリストの中の文字を含んでいる場合は、空の拡張文字を指定するのは良い考えではないかも知れません。

インプットに関しては、もし FIELDS ESCAPED BY 文字が空でなければ、その文字の発生は削除され、後続文字はフィールド値の一部として文字通りに取り込まれます。　例外は、拡張された ‘0’ または ‘N’ です。(例えば、もし拡張文字が ‘\’ なら \0 または \N です。)これらのシーケンスは、ASCII NUL (ゼロの値のバイト) と NULL として解釈されます。NULL の扱いのルールについてはこのセクションの後半で説明します。

‘\’-escape 構文の更なる情報については、項8.1. 「リテラル値」 を参照してください。

特定の場合には、field- と line-handling オプションは互いに影響しあいます。

NULL 値の扱いは、利用中の FIELDS と LINES オプションによって変わります。

NULL を NOT NULL カラムにロードしようとすると、カラムのデータ タイプと警告の為の暗黙のデフォルト値の割り当て、またはストリクト SQL モードでのエラーが発生します。暗黙のデフォルト値に関しては 項10.1.4. 「データタイプデフォルト値」 で説明されています。

LOAD DATA INFILE によってサポートされない場合もあります。

次の例は、persondata テーブルの全てのカラムをロードします。

LOAD DATA INFILE 'persondata.txt' INTO TABLE persondata;

デフォルトでは、LOAD DATA INFILE ステートメントの最後にカラムリストがない場合、インプット ラインが各テーブル カラムに対してフィールドを含みます。もし1つのテーブルのカラムをいくつかロードしたければ、カラム リストを指定してください。

LOAD DATA INFILE 'persondata.txt' INTO TABLE persondata (col1,col2,...);

インプット ファイル内のフィールドの順番が、テーブル内のカラムの順番と異なる場合は、カラム リストも指定しなければいけません。そうでなければ、MySQL はインプット フィールドとテーブル カラムをどのようにマッチさせるのか判断できません。

カラム リストはカラム名かユーザ変数のどちらかを含みます。ユーザ変数を利用すると、カラムに結果を割り当てる前に SET 条項で値を変換する事ができます。

SET 条項の中のユーザ変数は、いくつかの方法で利用する事ができます。次の例は、t1.column1 の値に対して直接最初のインプット カラムを利用し、そして2番目のインプット カラムを t1.column2 の値に利用される前に、分割操作に影響されるユーザ変数に割り当てます。

LOAD DATA INFILE 'file.txt'
  INTO TABLE t1
  (column1, @var1)
  SET column2 = @var1/100;

SET 条項は、インプット ファイルから派生した物ではない値を提供する事ができます。次のステートメントは、現在の日付と時間に column3 を設定する事ができます。

LOAD DATA INFILE 'file.txt'
  INTO TABLE t1
  (column1, column2)
  SET column3 = CURRENT_TIMESTAMP;

インプット値をユーザ変数に割り当て、変数をテーブル カラムに割り当てない事で、インプット値を廃棄する事ができます。

LOAD DATA INFILE 'file.txt'
  INTO TABLE t1
  (column1, @dummy, column2, @dummy, column3);

カラム/変数リストと SET 条項の利用は、次の制約を受けます。

インプット ラインを処理している時、LOAD DATA はそれをフィールドに分割し、カラム/変数リストと SET 条項があれば、それらに従って値を利用します。そして、結果としてできた行がテーブルに挿入されます。もしテーブルに BEFORE INSERT か AFTER INSERT トリガがあれば、それらはそれぞれ、行の挿入前か挿入後に起動されます。

もしインプット ラインのフィールドが多すぎたら、余分なフィールドは無視され、警告数が増加されます。

もしインプット ラインのフィールドが少なすぎたら、インプットフィールドがないテーブル カラムがそれらのデフォルト値として設定されます。デフォルト値の割り当てについては 項10.1.4. 「データタイプデフォルト値」 で説明しています。

空のフィールド値は、フィールド値がない場合とは異なって解釈されます。

これらは、INSERT や UPDATE ステートメントの中で、空の文字列を明示的に文字列、数値、または数値と時間タイプに割り当てた時の結果と同じ値です。

TIMESTAMP カラムは、カラムに NULL 値がある時(\N)、または、TIMESTAMP カラムのデフォルト値が現在のタイム スタンプの時だけ現在の日付と時間に設定され、カラムのデフォルト値はフィールド リストが指定された時に削除されます。

LOAD DATA INFILE は全てのインプットを文字列とみなしますので、INSERT ステートメントと同じ方法で、ENUM か SET カラムにも数値の値を利用する事ができます。全ての ENUM と SET 値は文字列として指定される必要があります。

BIT 値はバイナリ表記を利用してロードする事はできません。(例えば b'011010')これに対処するには、値を標準整数として指定し、それらの変換には、MySQL が数値タイプの変換を行う為に、SET 条項を利用し、そしてそれらを BIT カラムに正確にロードしてください。

shell> cat /tmp/bit_test.txt
2
127
shell> mysql test
mysql> LOAD DATA INFILE '/tmp/bit_test.txt'
    -> INTO TABLE bit_test (@var1) SET b= CAST(@var1 AS SIGNED);
Query OK, 2 rows affected (0.00 sec)
Records: 2  Deleted: 0  Skipped: 0  Warnings: 0

mysql> SELECT BIN(b+0) FROM bit_test;
+----------+
| bin(b+0) |
+----------+
| 10       |
| 1111111  |
+----------+
2 rows in set (0.00 sec)

LOAD DATA INFILE ステートメントが終了する時、次のフォーマットで情報文字列を返します。

Records: 1  Deleted: 0  Skipped: 0  Warnings: 0

もしC API を利用していれば、mysql_info() 関数を呼び出す事で、ステートメントの情報を得る事ができます。詳しくは 項23.2.3.35. 「mysql_info()」 を参照してください。

LOAD DATA INFILE もまた、インプット行のフィールドが多すぎる、または少なすぎる時に警告を生成するという事を除き、値が INSERT ステートメントを通して挿入された時と同じ状況下で警告が発生します。(項12.2.4. 「INSERT 構文」 を参照してください。) 警告はどこにも格納されません。警告数は、全てが順調であるかどうかを示す為だけに利用されます。

失敗した内容の情報を表す最初の max_error_count 警告のリストを得る為に、SHOW WARNINGS を利用する事ができます。詳しくは 項12.5.4.31. 「SHOW WARNINGS 構文」 を参照してください。

REPLACE [LOW_PRIORITY | DELAYED]
    [INTO] tbl_name [(col_name,...)]
    VALUES ({expr | DEFAULT},...),(...),...

または:

REPLACE [LOW_PRIORITY | DELAYED]
    [INTO] tbl_name
    SET col_name={expr | DEFAULT}, ...

または:

REPLACE [LOW_PRIORITY | DELAYED]
    [INTO] tbl_name [(col_name,...)]
    SELECT ...

REPLACE は、もしテーブル内の古い行が PRIMARY KEY か UNIQUE インデックスの新しい行と同じ値を持っていれば、古い行は新しい行が挿入される前に削除されるという事以外、INSERT と全く同じように機能します。詳しくは 項12.2.4. 「INSERT 構文」 を参照してください。

REPLACE は SQL スタンダードの MySQL 拡張子です。それは挿入、または 削除 と挿入を行います。挿入、または 更新 ? を行うスタンダード SQL ? の別の MySQL 拡張子に関しては、 項12.2.4.3. 「INSERT ... ON DUPLICATE KEY UPDATE 構文」 を参照してください。

テーブルが PRIMARY KEY か UNIQUE インデックスを持たなければ、REPLACE ステートメントの利用は何の意味も持たないという事を覚えておいてください。新しい行が別の行を複製するかどうかを決める為に利用するインデックスが無い為、それは INSERT と同等になります。

全てのカラムの値は、REPLACE ステートメントの中で指定された値から取られています。紛失したカラムは、INSERT と同じように、デフォルト値に設定されます。現在の行から値を参照し、それらを新しい行の中で利用する事はできません。もし、SET col_name = col_name + 1 のような割り当てを利用すると、右側のカラム名の参照は DEFAULT(col_name) として扱われるので、その割り当ては SET col_name = DEFAULT(col_name) + 1 と同等になります。

REPLACE を利用する為には、テーブルに対して INSERT と DELETE 権限の両方を持つ必要があります。

REPLACE ステートメントは、影響を受けた行数を表す為に総数を返します。これは、削除、挿入された行の総数です。もし単列 REPLACE の総数が1であれば、行が1つ挿入され、削除された行はないという事になります。 もし総数が1よりも大きければ、新しい行が挿入される前に、1つまたはそれ以上の行が削除されたという事になります。もしテーブルが複数の固有インデックスを含んでいれば、単列が複数の古い行を置き換える事が可能であり、そして新しい行は異なる固有のインデックス内の異なる古い行に値を複製します。

影響を受けた行の総数によって、REPLACE が行を追加しただけなのか、それとも行の置き換えも行ったのか、という事を簡単に知る事ができます。総数が1（追加された）か、それよりも大きい（置き換えが行われた）かを確認してください。

もしC API を利用していれば、mysql_affected_rows() 関数を利用する事で、影響を受けた行の総数を得る事ができます。

現在は、サブクエリの中で1つのテーブルに置き換え、同じテーブルから選択する事はできません。

MySQL は次のアルゴリズムを REPLACE (と LOAD DATA ... REPLACE)に利用します。

SELECT
    [ALL | DISTINCT | DISTINCTROW ]
      [HIGH_PRIORITY]
      [STRAIGHT_JOIN]
      [SQL_SMALL_RESULT] [SQL_BIG_RESULT] [SQL_BUFFER_RESULT]
      [SQL_CACHE | SQL_NO_CACHE] [SQL_CALC_FOUND_ROWS]
    select_expr, ...
    [FROM table_references
    [WHERE where_condition]
    [GROUP BY {col_name | expr | position}
      [ASC | DESC], ... [WITH ROLLUP]]
    [HAVING where_condition]
    [ORDER BY {col_name | expr | position}
      [ASC | DESC], ...]
    [LIMIT {[offset,] row_count | row_count OFFSET offset}]
    [PROCEDURE procedure_name(argument_list)]
    [INTO OUTFILE 'file_name' export_options
      | INTO DUMPFILE 'file_name'
      | INTO @var_name [, @var_name]]
    [FOR UPDATE | LOCK IN SHARE MODE]]

SELECT は、1つまたは複数のテーブルから選択した行を検索するために利用され、UNION ステートメントとサブクエリを含む事ができます。項12.2.7.2. 「UNION 構文」、項12.2.8. 「サブクエリ構文」 を参照して下さい。

一番良く利用される SELECT ステートメントの条項はこれらです。

SELECT もまた、別のテーブルへの参照無しで算出された行を検索する為に利用する事ができます。

例:

mysql> SELECT 1 + 1;
        -> 2

テーブルが参照されていない場合に、DUAL をダミー テーブルとして指定する事が許されています。

mysql> SELECT 1 + 1 FROM DUAL;
        -> 2

DUAL は純粋に、全ての SELECT ステートメントが FROM と、別の条項を持津事を要求する人々の為に役立つ物です。MySQL は条項を無視するかもしれません。 MySQL は、もしテーブルが参照されなければ FROM DUAL を要求しません。

通常、利用される条項は構文説明に表されるのと全く同じ順番で与える必要があります。例えば、HAVING 条項は GROUP BY 条項の前、ORDER BY 条項の後に来なければいけません。例外は、INTO 条項が構文の説明どおりに表される事も、FROM 条項の直前に先行して表される事も両方可能であるという事です。

SELECT キーワードの後で、ステートメントの操作に影響を与える幾つかのオプションを利用する事ができます。

ALL、DISTINCT、そして DISTINCTROW オプションは、複製行が返されるべきかどうかを指定します。もしこれらのオプションが何も与えられなければ、デフォルトは ALL です。(全ての一致する行が返されます。)DISTINCT と DISTINCTROW は同義語で、結果セットから複製行を削除する指示を出します。

HIGH_PRIORITY、STRAIGHT_JOIN、そして SQL_ で始まるオプションは、スタンダード SQL の MySQL 拡張子です。

table_references:
    table_reference [, table_reference] ...

table_reference:
    table_factor
  | join_table

table_factor:
    tbl_name [[AS] alias]
        [{USE|IGNORE|FORCE} INDEX (key_list)]
  | ( table_references )
  | { OJ table_reference LEFT OUTER JOIN table_reference
        ON conditional_expr }

join_table:
    table_reference [INNER | CROSS] JOIN table_factor [join_condition]
  | table_reference STRAIGHT_JOIN table_factor
  | table_reference STRAIGHT_JOIN table_factor ON condition
  | table_reference LEFT [OUTER] JOIN table_reference join_condition
  | table_reference NATURAL [LEFT [OUTER]] JOIN table_factor
  | table_reference RIGHT [OUTER] JOIN table_reference join_condition
  | table_reference NATURAL [RIGHT [OUTER]] JOIN table_factor

join_condition:
    ON conditional_expr
  | USING (column_list)

SELECT * FROM t1 LEFT JOIN (t2, t3, t4)
                 ON (t2.a=t1.a AND t3.b=t1.b AND t4.c=t1.c)

SELECT * FROM t1 LEFT JOIN (t2 CROSS JOIN t3 CROSS JOIN t4)
                 ON (t2.a=t1.a AND t3.b=t1.b AND t4.c=t1.c)

SELECT * FROM table1, table2;

SELECT * FROM table1 INNER JOIN table2 ON table1.id=table2.id;

SELECT * FROM table1 LEFT JOIN table2 ON table1.id=table2.id;

SELECT * FROM table1 LEFT JOIN table2 USING (id);

SELECT * FROM table1 LEFT JOIN table2 ON table1.id=table2.id
  LEFT JOIN table3 ON table2.id=table3.id;

SELECT * FROM table1 USE INDEX (key1,key2)
  WHERE key1=1 AND key2=2 AND key3=3;

SELECT * FROM table1 IGNORE INDEX (key3)
  WHERE key1=1 AND key2=2 AND key3=3;

SELECT ...
UNION [ALL | DISTINCT] SELECT ...
[UNION [ALL | DISTINCT] SELECT ...]

mysql> SELECT REPEAT('a',1) UNION SELECT REPEAT('b',10);
+---------------+
| REPEAT('a',1) |
+---------------+
| a             |
| bbbbbbbbbb    |
+---------------+

(SELECT a FROM t1 WHERE a=10 AND B=1)
UNION
(SELECT a FROM t2 WHERE a=11 AND B=2)
ORDER BY a LIMIT 10;

(SELECT a AS b FROM t) UNION (SELECT ...) ORDER BY b;
(SELECT a AS b FROM t) UNION (SELECT ...) ORDER BY a;

(SELECT a FROM t1 WHERE a=10 AND B=1 ORDER BY a LIMIT 10)
UNION
(SELECT a FROM t2 WHERE a=11 AND B=2 ORDER BY a LIMIT 10);

(SELECT 1 AS sort_col, col1a, col1b, ... FROM t1)
UNION
(SELECT 2, col2a, col2b, ... FROM t2) ORDER BY sort_col;

(SELECT 1 AS sort_col, col1a, col1b, ... FROM t1)
UNION
(SELECT 2, col2a, col2b, ... FROM t2) ORDER BY sort_col, col1a;

サブクエリは、別のステートメント内の SELECT ステートメントです。

MySQL 4.1 から、MySQL 特有のいくつかの特徴と同様に、SQL スタンダードが要求する全てのサブクエリ型と演算子がサポートされています。

ここに、同じようなサブクエリの例があります。

SELECT * FROM t1 WHERE column1 = (SELECT column1 FROM t2);

この例の中では、SELECT * FROM t1 ... は 外部クエリ (または 外部ステートメント)であり、(SELECT column1 FROM t2) は サブクエリ です。これは、サブクエリが外部クエリ内で ネスト化された という事であり、実際、サブクエリを別のサブクエリ内で、相当な深さまでネスト化する事が可能です。サブクエリは必ずカッコ内に表示されなければいけません。

サブクエリの主な利点は次のような物になります。

ここに、SQL スタンダードによって指定され、MySQL 内でサポートされているサブクエリ構文に関する主なポイントを説明するステートメントの例があります。

DELETE FROM t1
WHERE s11 > ANY
(SELECT COUNT(*) /* no hint */ FROM t2
WHERE NOT EXISTS
(SELECT * FROM t3
WHERE ROW(5*t2.s1,77)=
(SELECT 50,11*s1 FROM t4 UNION SELECT 50,77 FROM
(SELECT * FROM t5) AS t5)));

サブクエリは、スカラ(単一値)、単一行、単一カラム、またはテーブル(１つ、または複数カラムの、１つ、または複数行) を返す事ができます。これらはスカラ、カラム、行、そしてテーブル サブクエリと呼ばれます。次のセクションで説明されているように、頻繁に特定の種類の結果を返すサブクエリは、特定のコンテキストの中だけで利用する事ができます。

サブクエリを利用する事ができるステートメントのタイプには、いくつかの制限があります。サブクエリは、普通の SELECT が含む事のできるキーワードや条項を全て含む事ができます。それは DISTINCT、GROUP BY、ORDER BY、LIMIT、接合、インデックスヒント、UNION 構成、コメント、関数などです。

制限の１つは、サブクエリの外部ステートメントが SELECT、INSERT、UPDATE、DELETE、SET、または DO のうちのどれか１つでなければいけないという事です。その他の制限は、現在はサブクエリの中でテーブルを変更したり、同じテーブルから選択する事ができないという事です。これは、DELETE、INSERT、REPLACE、UPDATE、そして(サブクエリは SET 条項内で利用できる為) LOAD DATA INFILE のようなステートメントに適応します。

サブクエリ構文の特定型に関する性能問題を含む、サブクエリ利用に関する制限のさらなる総合的な説明に関しては、 項D.3. 「サブクエリの規制」 で紹介されています。

CREATE TABLE t1 (s1 INT, s2 CHAR(5) NOT NULL);
INSERT INTO t1 VALUES(100, 'abcde');
SELECT (SELECT s2 FROM t1);

CREATE TABLE t1 (s1 INT);
INSERT INTO t1 VALUES (1);
CREATE TABLE t2 (s1 INT);
INSERT INTO t2 VALUES (2);

SELECT (SELECT s1 FROM t2) FROM t1;

SELECT UPPER((SELECT s1 FROM t1)) FROM t2;

non_subquery_operand comparison_operator (subquery)

=  >  <  >=  <=  <>

  ... 'a' = (SELECT column1 FROM t1)

SELECT column1 FROM t1
WHERE column1 = (SELECT MAX(column2) FROM t2);

SELECT * FROM t1 AS t
WHERE 2 = (SELECT COUNT(*) FROM t1 WHERE t1.id = t.id);

operand comparison_operator ANY (subquery)
operand IN (subquery)
operand comparison_operator SOME (subquery)

SELECT s1 FROM t1 WHERE s1 > ANY (SELECT s1 FROM t2);

SELECT s1 FROM t1 WHERE s1 = ANY (SELECT s1 FROM t2);
SELECT s1 FROM t1 WHERE s1 IN    (SELECT s1 FROM t2);

SELECT s1 FROM t1 WHERE s1 <> ANY  (SELECT s1 FROM t2);
SELECT s1 FROM t1 WHERE s1 <> SOME (SELECT s1 FROM t2);

operand comparison_operator ALL (subquery)

SELECT s1 FROM t1 WHERE s1 > ALL (SELECT s1 FROM t2);

SELECT * FROM t1 WHERE 1 > ALL (SELECT s1 FROM t2);

SELECT * FROM t1 WHERE 1 > (SELECT s1 FROM t2);

SELECT * FROM t1 WHERE 1 > ALL (SELECT MAX(s1) FROM t2);

SELECT s1 FROM t1 WHERE s1 <> ALL (SELECT s1 FROM t2);
SELECT s1 FROM t1 WHERE s1 NOT IN (SELECT s1 FROM t2);

SELECT * FROM t1 WHERE (1,2) = (SELECT column1, column2 FROM t2);
SELECT * FROM t1 WHERE ROW(1,2) = (SELECT column1, column2 FROM t2);

  SELECT * FROM t1 WHERE (column1,column2) = (1,1);
  SELECT * FROM t1 WHERE column1 = 1 AND column2 = 1;

SELECT column1,column2,column3
FROM t1
WHERE (column1,column2,column3) IN
(SELECT column1,column2,column3 FROM t2);

SELECT column1 FROM t1 WHERE EXISTS (SELECT * FROM t2);

SELECT * FROM t1 WHERE column1 = ANY
(SELECT column1 FROM t2 WHERE t2.column2 = t1.column2);

SELECT column1 FROM t1 AS x
WHERE x.column1 = (SELECT column1 FROM t2 AS x
WHERE x.column1 = (SELECT column1 FROM t3
WHERE x.column2 = t3.column1));

val IN (SELECT key_val FROM tbl_name WHERE correlated_condition)

SELECT ... FROM (subquery) [AS] name ...

CREATE TABLE t1 (s1 INT, s2 CHAR(5), s3 FLOAT);

INSERT INTO t1 VALUES (1,'1',1.0);
INSERT INTO t1 VALUES (2,'2',2.0);
SELECT sb1,sb2,sb3
FROM (SELECT s1 AS sb1, s2 AS sb2, s3*2 AS sb3 FROM t1) AS sb
WHERE sb1 > 1;

SELECT AVG(SUM(column1)) FROM t1 GROUP BY column1;

SELECT AVG(sum_column1)
FROM (SELECT SUM(column1) AS sum_column1
FROM t1 GROUP BY column1) AS t1;

SELECT * FROM t1 WHERE id IN (SELECT id FROM t2);

SELECT DISTINCT t1.* FROM t1, t2 WHERE t1.id=t2.id;

SELECT * FROM t1 WHERE id NOT IN (SELECT id FROM t2);
SELECT * FROM t1 WHERE NOT EXISTS (SELECT id FROM t2 WHERE t1.id=t2.id);

SELECT table1.* FROM table1 LEFT JOIN table2 ON table1.id=table2.id
WHERE table2.id IS NULL;

TRUNCATE [TABLE] tbl_name

TRUNCATE TABLE はテーブルを完全に空にします。論理的には、これは全ての行を削除する DELETE ステートメントと同等ですが、いくつかの条件下では、違いがあります。

もしテーブルを参照する外部キー制約があれば、InnoDB テーブルに対しては、TRUNCATE TABLE が DELETE にマップされ、そうでなければ、高速切断(テーブルのドロップと再作成)が利用されます。外部キー制約の有無に関わらず、AUTO_INCREMENT カウンタが TRUNCATE TABLE によってリセットされます。

その他のストレージ エンジンに対しては、MySQL 5.1 の中では次のような方法で、TRUNCATE TABLE と DELETE が異なっています。

TRUNCATE TABLE は、MySQL 5.1.16 以降から DROP 権限を必要とします。(5.1.16 以前では DELETE 権限を必要としています。

TRUNCATE TABLE は MySQL に導入されたオラクル SQL 拡張子です。

単一テーブル構文:

UPDATE [LOW_PRIORITY] [IGNORE] tbl_name
    SET col_name1=expr1 [, col_name2=expr2 ...]
    [WHERE where_condition]
    [ORDER BY ...]
    [LIMIT row_count]

複合テーブル構文:

UPDATE [LOW_PRIORITY] [IGNORE] table_references
    SET col_name1=expr1 [, col_name2=expr2 ...]
    [WHERE where_condition]

単一テーブル構文には、UPDATE ステートメントは新しい値を利用して tbl_name 内に既存行のカラムを更新します。SET 条項は、どのカラムを変更し、それらにはどの値が与えられるべきかという事を指示します。もし WHERE 条項が与えられたら、それはどの行を更新するべきかを決定します。WHERE 条項が無ければ、全ての行が更新されます。もし ORDER BY 条項が指定されると、指定された順に行が更新されます。LIMIT 条項は、更新できる行数に制限を設定します。

複合テーブル構文には、UPDATE が、条件を満たす table_references で名づけられたそれぞれのテーブルの行を更新します。この場合、ORDER BY と LIMIT を利用する事はできません。

where_condition は更新される各行に対して正しい結果の式です。それは 項12.2.7. 「SELECT 構文」 で述べられている通りに指定されます。

UPDATE ステートメントは次の修飾因子をサポートします。

もし式の中で tbl_name からカラムにアクセスするなら、UPDATE はカラムの現在の値を利用します。例えば、次のステートメントは age カラムを現在の値よりも1大きく設定します。

UPDATE persondata SET age=age+1;

単一テーブル UPDATE 割り当ては通常左から右に評価されます。複合テーブルの更新に関しては、割り当てが特定の順番で行われるという保証はありません。

もし現在カラムが持つ値に設定するなら、MySQL はそれに気づくので更新はしません。

NULL に設定する事で NOT NULL を宣言されたカラムを更新すると、カラムはそのデータ タイプに適切なデフォルト値に設定され、警告カウントはインクリメントされます。数値タイプ、文字列タイプの空の文字列('')、そして日付と時刻タイプの「ゼロ」 値のデフォルト値は 0 です。

UPDATE は実際に変更された行数を返します。mysql_info() C API 関数は、一致し更新された行数と、UPDATE の最中に起きた警告数を返します。

UPDATE の領域を制限する為に LIMIT row_count を利用する事ができます。LIMIT 条項は行に一致した制限です。ステートメントは、実際に変更されたかどうかに関わらず、WHERE 条項の条件を満たす row_count 行を見付けるとすぐに止まります。

もし UPDATE ステートメントが ORDER BY 条項を含むなら、行は条項に指示された順番で更新されます。これは、エラーが起こるかもしれない特定の場合に有効です。テーブル t が固有インデックスを持つカラム id を含むと仮定してください。次のステートメントは、行が更新される順番によって、複製キー エラーとなり失敗するかもしれません。

UPDATE t SET id = id + 1;

例えば、もしテーブルが id カラム内に1と2を含み、2が3に更新される前に1が2に更新されると、エラーが起きます。 この問題を防ぐには、大きい id 値を持つ行が、小さい値を持つ行よりも先に更新されるように ORDER BY 条項を追加してください。

UPDATE t SET id = id + 1 ORDER BY id DESC;

複合テーブルをカバーする UPDATE 演算を行う事もできます。.しかし、複合テーブル UPDATE と共に ORDER BY や LIMIT を利用する事はできません。table_references 条項は接合箇所に含まれるテーブルをリストします。その構文は 項12.2.7.1. 「JOIN 構文」 で説明されています。ここに1つ例があります。

UPDATE items,month SET items.price=month.price
WHERE items.id=month.id;

前出の例はカンマ演算子を利用する内部接合を表しますが、複合テーブルの UPDATE ステートメントは、LEFT JOIN のような、SELECT ステートメント内で許容される接合タイプを利用する事ができます。

実際に更新された複合テーブル UPDATE の中で参照されたカラムに対してだけ、UPDATE 権限が必要です。読み込みはされても、変更はされないカラムには、SELECT 権限だけが必要です。

外部キー制限があるテーブルに InnoDB テーブルを含む複合テーブル UPDATE ステートメントを利用すると、MySQL のオプチマイザは、それらの親子関係の順番と違う順番でテーブルを処理するかもしれません。この場合、ステートメントは失敗し、ロールバックされます。代わりに、単一テーブルを更新し、他のテーブルが適宜修正されるように InnoDB が働きかける ON UPDATE 性能に頼ってください。

詳しくは 項13.5.6.4. 「FOREIGN KEY 制約」 を参照してください。

現在は、サブクエリの中で1つのテーブルを更新し、同じテーブルから選択する事はできません。

{DESCRIBE | DESC} tbl_name [col_name | wild]

DESCRIBE はテーブル内のカラムについて情報を提供します。これは、SHOW COLUMNS FROM へのショートカットです。これらのステートメントもまたビューの情報を表示します。（詳しくは 項12.5.4.4. 「SHOW COLUMNS 構文」 を参照してください。）

col_name は、カラム名、または SQL ‘%’ を含む文字列、そして文字列と一致する名前を持つカラムにだけアウトプットを取得する ‘_’ ワイルドカード文字になる事ができます。文字列がスペースやその他の特別な文字を含んでいない限り、それを引用句で囲む必要はありません。

mysql> DESCRIBE city;
+------------+----------+------+-----+---------+----------------+
| Field      | Type     | Null | Key | Default | Extra          |
+------------+----------+------+-----+---------+----------------+
| Id         | int(11)  | NO   | PRI | NULL    | auto_increment |
| Name       | char(35) | NO   |     |         |                |
| Country    | char(3)  | NO   | UNI |         |                |
| District   | char(20) | YES  | MUL |         |                |
| Population | int(11)  | NO   |     | 0       |                |
+------------+----------+------+-----+---------+----------------+
5 rows in set (0.00 sec)

Field はカラム名を指示します。

Null フィールドは NULL 値がカラムの中に格納する事ができるかどうかを指示します。

Key フィールドはカラムがインデックスされるかどうかを指示します。PRI の値は、カラムがそのテーブルの主キーの一部であるかどうかを指示します。UNI はそのカラムが UNIQUE インデックスの一部である事を指示します。MUL 値は与えられた値のカラム内での複合発生が許容されている事を指示します。

MUL が UNIQUE インデックス上に表示されるひとつの理由は、いくつかのカラムが複合 UNIQUE インデックスを形成するという事です。カラムの組み合わせが固有であっても、それぞれのカラムは与えられた値の複合発生を保持する事ができます。複合インデックスの中では、インデックスの左端のカラムだけが Key フィールド内でエントリーを持つという事に注意してください。

Default フィールドは、カラムに割り当てられたデフォルト値を指示します。

Extra フィールドは与えられたカラムについて有効な追加情報を含んでいます。表示された例の中で、Extra フィールドは Id カラムが AUTO_INCREMENT キーワードを利用して作成されたという事を指示しています。

CREATE TABLE ステートメントに基づいていると思っていた物とデータ タイプがもし異なっていたら、MySQL はデータ タイプを変更する事があるという事に注意してください。詳しくは 項12.1.8.1. 「サイレント カラム仕様変更」 を参照してください。

DESCRIBE ステートメントにはオラクルの互換性が提供されています。

SHOW CREATE TABLE と SHOW TABLE STATUS ステートメントもテーブルについての情報を提供します。詳しくは 項12.5.4. 「SHOW 構文」 を参照してください。

HELP 'search_string'

HELP ステートメントは MySQL リファレンス マニュアルからオンライン情報を返します。その正しい操作の為には mysql データベース内のヘルプ テーブルが、ヘルプ トピック情報で初期化さる必要があります。(項4.2.8. 「サーバ サイド ヘルプ」 を参照してください。)

HELP ステートメントは、ヘルプ テーブルの中で与えられた検索文字列を検索し、その結果を表示します。検索文字列は、大文字と小文字を区別しません。

HELP ステートメントはいくつかの検索文字列タイプを理解します。

言い換えると、検索文字列はカテゴリ、多くのトピック、または単一トピックに一致するという事です。あらかじめ、与えられた検索文字列が、項目リストや単一ヘルプ トピックのヘルプ情報を返すかどうかを知る事はできません。しかし、結果セットの中のカラムと行数を調べる事で、HELP がどのような答えを返したのかを知る事ができます。

次の説明は結果セットが取る事ができる形を指示します。ステートメント例のアウトプットは、mysql クライアントを利用する時に見る事ができる為になじみのある 「tabular」 や 「vertical」 フォーマットを利用して表示されますが、mysql 自体は HELP 結果セットを違う方法で再フォーマットする事に注意してください。

USE db_name

USE db_name ステートメントは、MySQL に対して、後に続くステートメントのデフォルト データベースとして db_name データベースを利用するように指示します。そのデータベースは、そのセッションが終わるまで、または別の USE ステートメントが発行されるまでデフォルトのままです。

USE db1;
SELECT COUNT(*) FROM mytable;   # selects from db1.mytable
USE db2;
SELECT COUNT(*) FROM mytable;   # selects from db2.mytable

USE ステートメントを利用して特定のデータベースをデフォルトにする事によって、別のデータベースの中でテーブルにアクセスする時に邪魔をする事はありません。次の例は、db1 データベースから author テーブルへ、そして db2 データベースから editor テーブルへアクセスします。

USE db1;
SELECT author_name,editor_name FROM author,db2.editor
  WHERE author.editor_id = db2.editor.editor_id;

USE ステートメントには Sybase の互換性が提供されています。

START TRANSACTION | BEGIN [WORK]
COMMIT [WORK] [AND [NO] CHAIN] [[NO] RELEASE]
ROLLBACK [WORK] [AND [NO] CHAIN] [[NO] RELEASE]
SET AUTOCOMMIT = {0 | 1}

START TRANSACTION と BEGIN ステートメントは新しいトランザクションを始めます。COMMIT は、その変更を恒久的な物にし、現在のトランザクションを行います。ROLLBACK はその変更をキャンセルし、現在のトランザクションをロールバックします。SET AUTOCOMMIT ステートメントは現在の接続にデフォルト自動コミット モードを無効に、そして有効にします。

任意の WORK キーワードは、CHAIN と RELEASE 条項のように COMMIT と ROLLBACK に対してサポートされています。CHAIN と RELEASE はトランザクション完了に対する追加コントロールに利用されます。completion_type システム変数の値はデフォルトの完了動作を決定します。詳しくは 項4.2.3. 「システム変数」 を参照してください。

AND CHAIN 条項は、現在のトランザクションが終わったらすぐに新しいトランザクションが始まるよう働きかけ、その新しいトランザクションは終わったばかりのトランザクションと同じ分離レベルを持ちます。RELEASE 条項は、現在のトランザクションを終了した後、サーバが現在のクライアント接続を切るよう働きかけます。NO キーワードを含む事は、もし completion_type システム変数がデフォルトで変更やリリース完了を引き起こすよう設定されれば有効となる、CHAIN や RELEASE 完了を食い止めます。

デフォルトにより、MySQL は自動コミットモードが有効な状態で起動します。これは、テーブルを更新（変更)するステートメントを実行したとたん、MySQL がディスク上に更新を格納する、という意味です。

もしトランザクション セーフ ストレージ エンジン(InnoDBや NDB Cluster のような物)を利用していたら、次のステートメントを利用して自動コミットモードを無効にする事ができます。

SET AUTOCOMMIT=0;

AUTOCOMMIT 変数をゼロに設定する事で自動コミット モードを無効にした後、ディスクに変更を格納する為には COMMIT を、またはもしそのトランザクションの最初から行ってきた変更を無視したければ ROLLBACK を利用しなければいけません。

一連のステートメントに対して自動コミット モードを無効にする為には、START TRANSACTION ステートメントを利用してください。

START TRANSACTION;
SELECT @A:=SUM(salary) FROM table1 WHERE type=1;
UPDATE table2 SET summary=@A WHERE type=1;
COMMIT;

START TRANSACTION を利用すると、自動コミットは COMMIT や ROLLBACK を利用してトランザクションを終了するまで無効のままです。そして自動コミット モードはその前の状態に戻ります。

BEGIN と BEGIN WORK は、トランザクションを始める START TRANSACTION のエイリアスとしてサポートされています。START TRANSACTION はスタンダード SQL 構文で、アドホック トランザクションを始める方法として推奨されています。

重要:MySQL クライアント アプリケーションを書く為に利用されている多くの API (JDBC のような)は、トランザクションを始める為に、クライアントから START TRANSACTION ステートメントを送る代わりに利用する事ができる（場合によっては利用しなければならない）独自の方法を提供します。更なる情報については、章?23. APIとライブラリー か、ご利用の API の説明書を参照してください。

BEGIN ステートメントは、BEGIN ... END 複合ステートメントを開始する BEGIN キーワードの利用とは異なります。後者はトランザクションを開始しません。詳しくは 項17.2.5. 「BEGIN ... END 複合ステートメント構文」 を参照してください。

このようにトランザクションを開始する事もできます。

START TRANSACTION WITH CONSISTENT SNAPSHOT;

WITH CONSISTENT SNAPSHOT 条項は、一貫性のある読み取りが可能であるストレージ エンジンに対して、それを開始します。現在は、これは InnoDB にだけ適応しています。その効果は、InnoDB テーブルから SELECT が後に続く START TRANSACTION を発行することと同じです。詳しくは 項13.5.10.4. 「一貫非ロック読み取り」 を参照してください。

WITH CONSISTENT SNAPSHOT 条項は現在のトランザクションの分離レベルを変更しないので、現在の分離レベルが一貫性のある読み取りを許容する物である場合のみ(REPEATABLE READ か SERIALIZABLE)、一貫性のあるスナップショットを提供します。

トランザクションを開始すると、未解決のトランザクションを引き起こします。詳細については、項12.4.3. 「暗黙のコミットを引き起こすステートメント」 をご参照ください。

トランザクションを開始すると、LOCK TABLES を利用して行ったテーブル ロックを、まるで UNLOCK TABLES を実行したかのように解除してしまいます。トランザクションを開始しても、FLUSH TABLES WITH READ LOCK を利用して行われたグローバル リード ロックの解除はしません。

一番良い結果を得る為には、単一トランザクショナル ストレージ エンジンによって管理されたテーブルだけを利用してトランザクションを行うべきです。そうでなければ、次のような問題が起きます。

各トランザクションは COMMIT によって、1つの塊でバイナリ ログの中に格納されています。ロールバックされたトランザクションはログされません。(例外:非トランザクション テーブルへの変更はロールバックされません。もしロールバックされたトランザクションが、非トランザクション テーブルへの変更を含んでいたら、それらのテーブルへの変更が複製される事を保障する為に、最後にそのトランザクション全体が ROLLBACK ステートメントでログされます。)詳しくは 項4.11.4. 「バイナリ ログ」 を参照してください。

SET TRANSACTION ISOLATION LEVEL を利用してトランザクションの分離レベルを変更する事ができます。詳しくは 項12.4.6. 「SET TRANSACTION 構文」 を参照してください。

ロールバックは、ユーザーが明示的に求めなくても行われる、ゆっくりとした操作になり得ます。 (例えば、エラーが発生した時。)この為、SHOW PROCESSLIST は、明示的、暗黙的な(ROLLBACK SQL ステートメント)ロールバックの最中の接続に対する State カラム内の Rolling back を表示します。

いくつかのステートメントはロールバックできません。通常、それらはデータベースを作成したりドロップしたりする物や、テーブルやストアド ルーチンを作成、ドロップ、変更する物のような、データ定義言語(DDL)ステートメントを含みます。

そのような物をトランザクション内に含まないようにデザインする必要があります。もしロールバックできないトランザクション内で、早いうちにステートメントを発行し、そして別のステートメントがその後失敗すると、そのような場合 ROLLBACK ステートメントを発行する事によってそのトランザクション全体の効果をロールバックする事はできません。

次の各ステートメント(そしてそれらの同義語)は、まるでステートメントを実行する前に COMMIT を行ったかのように、暗黙にトランザクションを終了します。

トランザクションはネスト化されません。これは、START TRANSACTION ステートメントかその同義語の1つを発行する時点でのトランザクションに対して実行される、暗黙的な COMMIT の結果です。

トランザクションが ACTIVE 状態の間は、暗黙的な作業を引き起こすステートメントは XA トランザクションでは利用する事はできません。

SAVEPOINT identifier
ROLLBACK [WORK] TO SAVEPOINT identifier
RELEASE SAVEPOINT identifier

InnoDB は SQL ステートメント SAVEPOINT、ROLLBACK TO SAVEPOINT、RELEASE SAVEPOINT そして ROLLBACK の任意 WORK キーワードをサポートします。

SAVEPOINT ステートメントは identifier の名前を利用して、名前が付けられたトランザクション セーブポイントを設定します。もし現在のトランザクションが同名のセーブポイントを持っていれば、古いセーブポイントは削除され新しいものが設定されます。

ROLLBACK TO SAVEPOINT ステートメントは、名づけられたセーブポイントにトランザクションをロールバックします。セーブポイントの設定後に行に対して現在のトランザクションが行った変更はロールバック内で解除されますが、InnoDB はセーブポイントの後にメモリに格納された新しい行ロックのリリースは 行いません。(新しく挿入された行には、その行内に格納されているトランザクション ID によってロック情報が保持されるので、そのロックはメモリの中で別々に格納される訳ではないという事に注意してください。この場合、行ロックは取り消しの中でリリースされます。)名づけられたセーブポイントよりも後で設定されたセーブポイントは削除されます。

もし ROLLBACK TO SAVEPOINT ステートメントが次のエラーを返したら、指定された名前のセーブポイントは存在しないという事を意味します。

ERROR 1181: Got error 153 during ROLLBACK

RELEASE SAVEPOINT ステートメントは、現在のトランザクションのセーブポイント セットから、名づけられたセーブポイントを除外します。コミットもロールバックも起きません。もしセーブポイントが存在しなければ、これはエラーになります。

もし COMMIT や、セーブポイントに名前をつけない ROLLBACK を実行すると、現在のトランザクションの全てのセーブポイントは削除されます。

MySQL 5.0.17 から、ストアド ファンクションが呼び出されたりトリガが作動した時に、新しいセーブポイント レベルが作成されます。以前のレベルのセーブポイントは無効になる為、新しいレベルとの間でセーブポイントの衝突が起きません。ファンクションやトリガが終了する時に、それらが作成したセーブポイントはリリースされ、以前のセーブポイント レベルが保持されます。

LOCK TABLES
    tbl_name [AS alias]
      {READ [LOCAL] | [LOW_PRIORITY] WRITE}
    [, tbl_name [AS alias]
      {READ [LOCAL] | [LOW_PRIORITY] WRITE}] ...
UNLOCK TABLES

LOCK TABLES は、現在のスレッドに対してベース テーブル (ビュー以外) をロックします。もしテーブルが1つでも他のスレッドによってロックされていたら、それは全てのロックを入手するまでブロックします。

UNLOCK TABLES は現在のスレッドによって行われたロックを全て明示的にリリースします。スレッドが別の LOCK TABLES を発行した時、またはサーバへの接続が閉じられた時に、現在のスレッドにロックされている全てのテーブルは暗黙的にロック解除されます。 UNLOCK TABLES はまた、FLUSH TABLES WITH READ LOCK を利用してグローバル リード ロックを取得した後に、そのロックをリリースする為に利用されます。(FLUSH TABLES WITH READ LOCK ステートメントによってリード ロックされている全てのデータベース内の全てのテーブルをロックする事ができます。詳しくは 項12.5.5.2. 「FLUSH 構文」 を参照してください。これは、もし Veritas のような時間内にスナップショットを撮る事ができるファイルシステムを持っていると、バックアップを取るのが大変便利な方法になります。)

LOCK TABLES を利用する為には、関連するテーブルに対して LOCK TABLES 権限と SELECT 権限を持つ必要があります。

LOCK TABLES を利用する主な理由は、テーブルを更新する際にトランザクションをエミュレートしたり、スピードを早くしたりする事です。後ほどもう少し詳しく説明します。

テーブル ロックは、別のクライアントによる不適切な読み込みや書き込みに対してのみ保護します。ロックを保持しているクライアントは、それがリード ロックだとしても、DROP TABLE のようなテーブル レベル操作を行う事ができます。切り捨て操作はトランザクション セーフではないので、もし、アクティブなトランザクションの実行中や、テーブル ロックを保持している最中にクライアントがそれを行おうとすると、エラーが発生します。

LOCK TABLES とトランザクション テーブルを共に利用する際には、次の事に注意してください。

LOCK TABLES を利用する時、ステートメントの中で利用する予定の全てのテーブルをロックしなければいけません。LOCK TABLES はビューをロックしないので、もし今実行している操作がビューを利用するなら、それらのビューが依存する全てのベース テーブルもロックしなければいけません。LOCK TABLES ステートメントで取得したロックが有効な間は、そのステートメントによってロックされていないテーブルにアクセスする事はできません。また、単一クエリの中でロックされたテーブルを複数回使用する事はできません。各エイリアスに対して別々にロックを取得する必要がある場合には、代わりにエイリアスを利用してください。

mysql> LOCK TABLE t WRITE, t AS t1 WRITE;
mysql> INSERT INTO t SELECT * FROM t;
ERROR 1100: Table 't' was not locked with LOCK TABLES
mysql> INSERT INTO t SELECT * FROM t AS t1;

もしステートメントがエイリアスを利用してテーブルを参照するなら、同じエイリアスを利用してテーブルをロックする必要があります。エイリアスを指定しないでテーブルをロックする事はできません。

mysql> LOCK TABLE t READ;
mysql> SELECT * FROM t AS myalias;
ERROR 1100: Table 'myalias' was not locked with LOCK TABLES

反対に、もしエイリアスを利用してテーブルをロックすると、そのエイリアスを利用してステートメント内でそのテーブルを参照する必要があります。

mysql> LOCK TABLE t AS myalias READ;
mysql> SELECT * FROM t;
ERROR 1100: Table 't' was not locked with LOCK TABLES
mysql> SELECT * FROM t AS myalias;

もしスレッドがテーブル上で READ ロックを取得したら、そのスレッド(そしてそれ以外の全てのスレッド)はテーブルからは読み込む事しかできません。もしスレッドがテーブル上で WRITE ロックを取得したら、そのロックを保持するスレッドのみがそのテーブルに書き込みができます。ロックが解除されるまで、その他のスレッドはテーブルの読み込み、書き込みからブロックされます。

READ LOCAL と READ の違いは、READ LOCAL は、ロックされている間に非対立 INSERT ステートメント(並列挿入)が実行される事を許容するという事です。しかし、もしロックを保持している間に MySQL の外部でデータベース ファイルを複製しようとすると、これを利用する事はできません。 InnoDB テーブルに対しては、READ LOCAL は READ と同じです。

WRITE ロックは通常、更新がなるべく速く行われるよう、READ ロックよりも高い優先順位を持ちます。これは、もし1つのスレッドが READ ロックを取得し、そして別のスレッドが WRITE ロックをリクエストすると、後続の READ ロックリクエストは、WRITE スレッドがロックを得て、それをリリースするまで待つ、という意味になります。WRITE ロックを待っているスレッドの前に、別のスレッドが READ ロックを取得するのを許容する為に、LOW_PRIORITY WRITE を利用する事ができます。READ ロックを持つスレッドが無い時に、時間が残っている事が確実である時だけ、LOW_PRIORITY WRITE ロックを利用しなければいけません。(例外:トランザクション モード(自動コミット = 0)の InnoDB テーブルに対しては、LOW_PRIORITY WRITE ロックは通常の WRITE ロックのように機能し、待機中の READ ロックに先行します。)

LOCK TABLES は次のように機能します。

.この方法は、テーブル ロックにデッドロックが起きない事を保証します。:しかし、この方法について知っておかなければいけない事があります。もしテーブルに対して LOW_PRIORITY WRITE ロックを利用していたら、MySQL は READ ロックを必要とするスレッドがなくなるまで、この特定のロックを待つ、という意味になります。スレッドが WRITE ロックを得て、ロック テーブル リストの中の次のテーブルのロックを得るのを待っている時、他の全てのスレッドは WRITE ロックが解除されるのを待ちます。もしこれが、ご利用のアプリケーションにとって深刻な問題となってしまったら、いくつかのテーブルをトランザクション セーフ テーブルに変換する事を考慮するべきです。

テーブル ロックを待っているスレッドを終了させる為に、KILL を安全に使用する事ができます。詳しくは 項12.5.5.3. 「KILL 構文」 を参照してください。

INSERT が別のスレッドによって実行されてしまう為、INSERT DELAYED と共に利用しているテーブルをロック してはいけない という事に注意してください。

通常、全ての単一 UPDATE ステートメントはアトミックなので、テーブルをロックする必要はありません。別のスレッドが現在実行中の SQL ステートメントの邪魔をする事はできません。しかし、テーブルをロックする事が利益をもたらす場合もいくつかあります。

多くの場合、相対更新(UPDATE customer SET value=value+new_value)または LAST_INSERT_ID() 関数を利用する事で、LOCK TABLES の利用を避ける事ができます。詳しくは 項1.8.5.3. 「トランザクションとアトミックオペレーション」 を参照してください。

ユーザ レベルの通知ロック機能 GET_LOCK() と RELEASE_LOCK() を利用する事で、テーブルのロックを避ける事ができる場合があります。これらのロックははサーバ内のハッシュ テーブルの中に保存され、スピードを速くする目的で pthread_mutex_lock() と pthread_mutex_unlock() を利用して実施されます。詳しくは 項11.10.4. 「その他の関数」 を参照してください。

ロックの規定に関しての更なる情報は 項6.3.1. 「MySQL のテーブルロック方法」 を参照してください。

注意:もしロックされたテーブル上に ALTER TABLE を利用すると、ロックが解除される可能性があります。詳しくは 項B.1.7.1. 「Problems with ALTER TABLE」 を参照してください。

SET [GLOBAL | SESSION] TRANSACTION ISOLATION LEVEL
{ READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE }

このステートメントは、次のトランザクションにグローバルに分離レベルを設定したり、現在のセッションに分離レベルを設定したりします。

SET TRANSACTION のデフォルト動作は、次の（まだ始まっていない）トランザクションの分離レベルを設定する事です。もし GLOBAL キーワードを利用すると、そのステートメントはその時点以降に作成された全ての新しい接続に対して、デフォルトのトランザクション レベルをグローバルに設定します。既存接続には影響はありません。これには SUPER 権限が必要です。SESSION キーワードの利用は、現在の接続上で今後行われる全てのトランザクションに対して、デフォルト トランザクション レベルを設定します。

各 InnoDB トランザクション分離レベルの説明に関しては、項13.5.10.3. 「InnoDB と TRANSACTION ISOLATION LEVEL」 を参照してください。InnoDB は MySQL 5.1 内でこれらそれぞれのレベルをサポートします。デフォルト レベルは REPEATABLE READ です。

mysqld に冒頭のデフォルト グローバル分離レベルを設定する為には、--transaction-isolation オプションを利用してください。詳しくは 項4.2.2. 「コマンド オプション」 を参照してください。

InnoDB ストレージ エンジンでは、XA トランザクションがサポートされています。MySQL XA インプリメンテーションは X/Open CAE ドキュメント Distributed Transaction Processing:XA 仕様 に基づいています。この文書はオープン グループによって出版されていて、http://www.opengroup.org/public/pubs/catalog/c193.htm で入手可能です。現在の XA インプリメンテーションの制限については、 項D.5. 「XA トランザクションの規制」 で説明されています。

クライアント側には、特別な事は何も要求されません。MySQL サーバへの XA インターフェースは、XA キーワードで始まる SQL ステートメントで構成されています。MySQL クライアント プログラムは、SQL ステートメントを送り、XA ステートメント インターフェースの動作を理解する事が可能である必要があります。それらは最近のクライアント ライブラリに違反してリンクされる必要はありません。古いクライアント ライブラリもまた機能します。

現在、MySQL コネクタの中では、MySQL コネクタ/J 5.0.0 が XA ディレクトリをサポートします。 (XA SQL ステートメント インターフェースを扱うクラス インターフェースを利用して)

XA は分散型のトランザクションをサポートします。それは、複数の別々のトランザクション リソースを、グローバル トランザクションに参加させる事ができる能力です。トランザクション リソースは RDBMS である事が多いのですが、別の種類である可能性もあります。

グローバル トランザクションは、それら自身の中でトランザクションのアクションをいくつか含んでいますが、それらは全て、グループとして成功するか、グループとしてロールバックされる必要があります。要するに、これは複数の ACID トランザクションが、ACID 特性を持つグローバル操作のコンポーネントとして一斉に実行されるように ACID 特性を 「1レベル上げる」 という事です。(しかし、分散型のトランザクションには、ACID 特性を達成する為に、SERIALIZABLE 分離レベルを利用しなければいけません。非分散型のトランザクションには REPEATABLE READ の利用で十分ですが、分散型のトランザクションに対しては十分では有りません。)

分散型トランザクションのいくつかの例

グローバル トランザクションを利用するアプリケーションは、1つ、または複数のリソース マネージャと、1つのトランザクション マネージャを含んでいます。

XA MySQL の MySQL インプリメンテーションは、MySQL サーバがグローバル トランザクション内で XA トランザクションを扱うリソース マネージャとして機能する事を可能にします。MySQL サーバに接続するクライアントプログラムは、トランザクション マネージャとして機能します。

グローバル トランザクションを実行するには、どのコンポネントが関係しているかを知り、それらをそれぞれ、コミットまたはロールバックできる時にポイントまで持ってくる事が必要です。 各コンポネントがそれぞれの能力についてどのようなレポートをするかによって、それらは全て1つのアトミック グループとしてコミット、またはロールバックしなければいけません。 それは、全てのコンポネントがコミットするか、または全てのコンポネントがロールバックするという事です。グローバル トランザクションを管理するには、コンポネントか、接続ネットワークが失敗する可能性があるという事を考慮に入れておく事が必要です。

グローバル トランザクションを実行するプロセスは、二相コミットを利用します。(2PC)これは、グローバル トランザクションのブランチによって行われるアクションが実行された後に起こります。

場合によっては、グローバル トランザクションは単相コミットを利用します。(1PC)例えば、トランザクション マネージャがたった1つのトランザクション リソースで成り立っているグローバル トランザクションを見つけたら(それを単一ブランチといいます)、そのリソースには準備とコミットを同時にするように指示が出されます。

XA {START|BEGIN} xid [JOIN|RESUME]

XA END xid [SUSPEND [FOR MIGRATE]]

XA PREPARE xid

XA COMMIT xid [ONE PHASE]

XA ROLLBACK xid

XA RECOVER

xid: gtrid [, bqual [, formatID ]]