MySQL リファレンスマニュアル :: 6.5.3 CREATE TABLE 構文

NULL も NOT NULL も指定されていない場合、カラムは NULL が指定されているときと同じように処理される。

整数型カラムは追加属性 AUTO_INCREMENT を持つことができる。 インデックス付きの AUTO_INCREMENT カラムに NULL（推奨）または 0 を挿入すると、そのカラムには連続値の次の値が設定される。 通常、これは value+1 になる（value はテーブルに現在格納されているそのカラムの最大値）。 AUTO_INCREMENT は 1 から開始される。 See 項11.1.3.32. 「mysql_insert_id()」。

MySQL 4.1.1 以降では、--sql-mode サーバオプションまたは sql_mode サーバ変数に対して NO_AUTO_VALUE_ON_ZERO フラグを指定することによって、新しい連続値を生成する代わりに、AUTO_INCREMENT カラムに 0 を 0 として格納することができる。 See 項4.1.1. 「mysqld コマンドラインオプション」。

AUTO_INCREMENT カラムの最大値が入ったレコードを削除した場合、その値は ISAM テーブルや BDB テーブルでは再利用されるが、MyISAM テーブルや InnoDB テーブルでは再利用されない。DELETE FROM table_name（WHERE 節なし）を AUTOCOMMIT モードで実行してテーブル内のすべてのレコードを削除した場合、InnoDB を除くすべてのテーブル型で、連続値が初めから開始される。 See 項7.5.12.5. 「InnoDB での AUTO_INCREMENT カラムの仕組み」。

注意: AUTO_INCREMENT カラムはテーブルごとに 1 つだけ存在できる。このカラムにはインデックスを付ける必要があり、また DEFAULT 値は設定できない。 MySQL バージョン 3.23 では、AUTO_INCREMENT カラムは、正の値だけを持つ場合にのみ正しく機能する。負の数値が挿入されると、その値はきわめて大きな正数としてみなされる。 これは、数値が正の数から負の数に ``折り返す'' ときに発生する精度の問題を回避するためと、0 が入った AUTO_INCREMENT カラムが誤って取得されないようにするためである。

MyISAM テーブルと BDB テーブルでは、複合インデックスで AUTO_INCREMENT セカンダリカラムを指定できる。 See 項3.6.9. 「AUTO_INCREMENT の使用」。

MySQL と一部の ODBC アプリケーションとの互換性を確保するため、最後に挿入されたレコードの AUTO_INCREMENT 値を次のクエリで検出することができる。

SELECT * FROM tbl_name WHERE auto_col IS NULL

TIMESTAMP 型カラムでは、他のカラム型とは異なる方法で NULL 値が処理される。TIMESTAMP 型カラムには、NULL は格納できない。カラムに NULL を挿入すると、カラムの値として現在の日時が設定される。TIMESTAMP 型のカラムはこのように動作するため、NULL 属性と NOT NULL 属性は通常どおりには適用されず、それらを指定しても無視される。

その一方で、TIMESTAMP 型のカラムを MySQL クライアントにとって使用しやすくするために、サーバは、（実際には、TIMESTAMP 型カラムには NULL 値は格納されないにもかかわらず）TIMESTAMP 型カラムについて、NULL 値の割り当てが可能（true）と報告する。DESCRIBE tbl_name を使用してテーブルに関する記述を取得すると、これを確認できる。

注意: TIMESTAMP 型のカラムに、値として 0 を設定するのは、NULL を設定するのとは異なる。0 は TIMESTAMP 型の有効な値である。

DEFAULT 値は定数でなければならず、関数や式を使用することはできない。

DEFAULT 値が指定されていない場合、そのカラムには、次の方法で、MySQL によって DEFAULT 値が自動的に割り当てられる。

値として NULL を取れるカラムの場合、デフォルト値は NULL になる。

NOT NULL として宣言されているカラムの場合、デフォルト値はそれぞれのカラム型によって決まる。

デフォルト値は定数でなければならない。したがって、日付カラムのデフォルト値として、NOW() や CURRENT_DATE などの関数を設定することはできない。

COMMENT オプションでは、カラムに関するコメントを指定することができる。 コメントは SHOW CREATE TABLE ステートメントと SHOW FULL COLUMNS で表示される。 このオプションは MySQL 4.1 から利用可能（それ以前のバージョンでは、使用は可能だが無視される）。

KEY は、通常 INDEX のシノニム。 バージョン 4.1 以降、キー属性 PRIMARY KEY は単に KEY として指定することもできる。この機能は他のデータベースとの互換性を考慮して実装された。

MySQL では、UNIQUE キーには重複のない値以外は格納できない。 既存のレコードのキーと同じキーを持つ新しいレコードを追加しようとすると、エラーが発生する。

PRIMARY KEY は、すべてのキーカラムが NOT NULL として定義されていなければならないユニーク KEY である。NOT NULL として明示的に定義されていないと、暗黙的（かつ自動的）に NOT NULL に設定される。MySQL において、このキーは PRIMARY と呼ばれる。個々のテーブルは PRIMARY KEY を 1 つだけ持つことができる。 PRIMARY KEY がない場合に、何らかのアプリケーションがテーブルの PRIMARY KEY を要求すると、MySQL では、NULL カラムをまったく持たない最初の UNIQUE キーが PRIMARY KEYとして返される。

複合インデックスを PRIMARY KEY にすることもできる。しかし、カラムの仕様で PRIMARY KEY キー属性を使用して複合インデックスは作成することはできない。そのようにしても、単一のカラムがプライマリとしてマークされるにすぎない。 この場合、別に PRIMARY KEY(index_col_name, ...) 節を使用する必要がある。

UNIQUE インデックスでは、インデックスのすべての値に重複がない状態でなければならない。ただし、例外として、そのインデックスのカラムの 1 つで NULL 値が格納可能な場合、複数の NULL 値を格納できる。 この例外は BDB 型のテーブルには適用されない。BDB 型のテーブルには単一の NULL のみ格納可能。

PRIMARY キーまたは UNIQUE キーが単一のカラムで構成されていて、そのカラム型が整数型の場合、そのキーは _rowid として参照することもできる（バージョン 3.23.11 の新機能）。

PRIMARY KEY でないインデックスに名前を割り当てないと、そのインデックスは index_col_name の最初のカラム名と同じ名前が割り当てられ、そのインデックスを一意（ユニーク）なものとするためのオプションのサフィックス（_2、_3、...）が付けられる。テーブルのインデックス名は SHOW INDEX FROM tbl_name を使用して確認できる。 See 項4.6.8.1. 「データベース、テーブル、カラム、およびインデックスに関する情報の取得」。

NULL 値を持つことができるカラムに対するインデックスの作成は、MyISAM、InnoDB、BDB の各テーブル型でのみサポートしている。その他のテーブルでは、カラムが NOT NULL と宣言されていないとエラーになる。

インデックスの指定で col_name(length) 構文を使用することによって、CHAR 型または VARCHAR 型カラムの最初から length に指定した長さのバイトのみを使用するインデックスを作成できる。この方法で、インデックスファイルのサイズをかなり小さくすることができる。 See 項5.4.4. 「カラムインデックス」。

BLOB 型と TEXT 型のカラムのインデックスの作成は、MyISAM テーブルと（MySQL 4.0.14 以降の）InnoDB テーブルでのみサポートしている。BLOB 型または TEXT 型のカラムにインデックスを付けるときには、インデックスの長さ（最大 255 バイト）を必ず指定する必要がある。次に例を示す。

CREATE TABLE test (blob_col BLOB, INDEX(blob_col(10)));

index_col_name の指定では、最後に ASC または DESC を付けることができる。 これらのキーワードは、昇順または降順によるインデックス値の格納を指定できるようにする今後の拡張に対応している。現時点では、これらのキーワードは解析されるが無視される。インデックス値は常に昇順で格納される。

TEXT 型または BLOB 型のカラムで ORDER BY または GROUP BY が使用されていると、サーバは、最初の部分の、 max_sort_length サーバ変数が示す数のバイトのみを使用して値をソートする。 See 項6.2.3.2. 「BLOB 型と TEXT 型」。

MySQL バージョン 3.23.23 以降では、特殊な FULLTEXT インデックスも作成できる。これは全文検索に使用される。FULLTEXT インデックスは、MyISAM テーブルでのみサポートしている。このインデックスは、CHAR 型、VARCHAR 型、TEXT 型のカラムからのみ作成できる。 インデックスの作成は常にカラム全体に対して行われる。部分的なインデックスの作成は行われない。処理の詳細については、項6.8. 「MySQL 全文検索」 を参照。

MySQL バージョン 3.23.44 以降では、InnoDB テーブルで外部キー制約のチェックをサポートしている。See 項7.5. 「InnoDB テーブル」。 注意: InnoDB での FOREIGN KEY 構文は上に示した構文より制限されている。参照テーブルのカラム名は、必ず明示的に指定する必要がある。 InnoDB では、MySQL 3.23.50以降、外部キーに対する ON DELETE アクションを、また MySQL 4.0.8 以降では ON UPDATE アクションをサポートしている。 正確な構文については、このマニュアルの InnoDB のセクションを参照。 See 項7.5.5.2. 「FOREIGN KEY 制約」。 他のテーブル型については、MySQL サーバは CREATE TABLE コマンドの FOREIGN KEY、CHECK、REFERENCES の各構文を解析するが、それ以上の処理は行わない。 See 項1.8.4.5. 「外部キー」。

MyISAM テーブルと ISAM テーブルの場合、各 NULL カラムは 1 ビット余分に使用して、最も近いバイトに切り上げられる。 バイトでの最大レコード長は次のように計算される。

レコード長 = 1
             + (カラム長の合計)
             + (NULL カラムの数 + delete_flag + 7)/8
             + (可変長カラムの数)

静的レコード形式のテーブルでは、delete_flag は 1。静的テーブルでは、行レコードで、そのレコードが削除されたものであるかを示すフラグ用に 1 ビットが使用される。動的テーブルでは、このフラグは可変長レコードの頭に格納されるため、delete_flag は 0 になる。

これらの計算は InnoDB テーブルには適用されない。InnoDB テーブルでは、NULL カラムの格納サイズは NOT NULL カラムと比較して変わらない。

table_options オプションと SELECT オプションは MySQL バージョン 3.23 以降でのみ実装されている。

テーブル型を指定する TYPE オプションは次の値を取る。

See 章 7. MySQL のテーブル型。

テーブル型が指定されているときに、そのテーブル型が使用できない場合、MySQL では、代わりに MyISAM が使用される。 たとえば、テーブル定義に TYPE=BDB オプションが含まれているときに、BDB 型のテーブルを MySQL サーバでサポートしていない場合、テーブルは MyISAM テーブルとして作成される。そのため、マスタにトランザクションテーブルがありながら、スレーブでは非トランザクションテーブルを作成する（速度を上げるため）といった、レプリケーション設定が可能になる。MySQL 4.1.1 では、指定したテーブル型が受け付けられないと警告が出力される。

その他のテーブルオプションは、テーブルの動作を最適化するために使用される。ほとんどの場合、これらはいずれも指定しなくてよい。 これらのオプションは、特に断りがない限り、すべてのテーブル型に適用される。

MyISAM テーブルの使用時には、MySQL で、MAX_ROWS * AVG_ROW_LENGTH の積によって、結果のテーブルがどれくらいのサイズになるかの計算が行われる。上記のオプションのどれも指定しないと、テーブルの最大サイズは 4G（使用しているオペレーティングシステムで 2G のテーブルしかサポートされていないときは 2G）になる。その理由は、単に大きなファイルが必要でない場合に、ポインタのサイズを抑制することによって、インデックスをより小さく、より迅速化することにある。

PACK_KEYS を指定しないと、デフォルトでは、文字列のパックのみ行われ、数値のパックは行われない。PACK_KEYS=1 と指定すると、数値もパックされる。

バイナリ数値キーのパック時には、MySQL によってプリフィックスの圧縮が行われる。 つまり、これによって大きな利益を得られるのは、同じ数値が数多く存在する場合に限られる。プリフィックスの圧縮では、前のキーの何バイトが次のキーと同じであるかを示す追加の 1 バイトが各キーで必要になる（注意: 圧縮のパフォーマンスを良くするため、キーの直後に、レコードのポインタが上位バイトから下位バイトの順に格納される）。したがって、連続する 2 つのレコードに同じキーが数多くあるとき、通常、``同じ'' キーの後に続くものはいずれも 2 バイト（レコードのポインタも含めて）しか取らない。それに比べて通常の場合は、後に続くキーで storage_size_for_key + pointer_size 分（通常 4 バイト）必要になる。その一方、すべてのキーがまったく異なる場合は、NULL 値を持てない各キーで 1 バイト余分に使用される（この場合、パックされたキーの長さは、キーが NULL であるかどうかを示すバイトと同じバイトに格納される）。

MySQL 3.23 以降では、CREATE ステートメントの後に SELECT を指定すると、SELECT のすべての要素に対応する新しいフィールドが MySQL によって作成される。次に例を示す。

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

この場合、a、b、c の 3 つのカラムを持つ 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 では、インデックスの作成は自動では行われない。これは、このコマンドをできるだけ柔軟なものにするためである。作成するテーブルにインデックスが必要な場合は、SELECT ステートメントの前にインデックスを指定する。

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

テーブルへのデータのコピー時にエラーが発生した場合、データは自動で削除される。

SELECT の前に IGNORE または REPLACE を付けることで、ユニークキー値が重複するレコードの処理方法を指定できる。 IGNORE の場合、新しいレコードのユニークキー値が既存のレコードの値と重複していると、その新しいレコードは破棄される。REPLACE の場合、新しいレコードによって、同じユニークキー値を持つ既存のレコードが置換される。IGNORE と REPLACE のどちらも指定していない場合、ユニークキー値の重複が検出されるとエラーになる。

更新ログやバイナリログを使用して元のテーブルを確実に再作成できるようにするため、MySQL では CREATE TABLE ... SELECT 実行中の同時挿入は行えない。

RAID_TYPE オプションでは、大きなファイルをサポートしていないオペレーティングシステムで MyISAM データファイル（インデックスファイルではなく）に対する 2G または 4G の制限を超すことができる。注意: このオプションは大きなファイルをサポートしているファイルシステムでは推奨されない。

異なる物理ディスク上に RAID ディレクトリを配置することによって I/O のボトルネックを迅速化することができる。RAID_TYPE はあらゆるオペレーティングシステムで機能するが、MySQL のコンフィギャを --with-raid として行っておく必要がある。現時点で使用可能な RAID_TYPE は STRIPED（1 と RAID0 はこのエイリアス）。

MyISAM テーブルに対して RAID_TYPE=STRIPED と指定すると、データベースディレクトリに、00、01、02 という RAID_CHUNKS サブディレクトリが MyISAM によって作成される。これらのディレクトリのそれぞれで、table_name.MYD が MyISAM によって作成される。データファイルへのデータの書き込み時、RAID ハンドラによって、最初の RAID_CHUNKSIZE *1024 バイトが最初のファイルにマップされ、次の RAID_CHUNKSIZE *1024 バイトが次のファイルにマップされる（以下同様）。

UNION は、同一テーブルのコレクションを 1 つのものとして使用する場合に指定する。これは、MERGE テーブルに対してのみ機能する。 See 項7.2. 「MERGE テーブル」。

現在のところ、MERGE テーブルにマップするテーブルに対する SELECT、UPDATE、DELETE の各権限が必要になる。 マップ対象のテーブルはいずれも MERGE テーブルと同じデータベースに存在しなければならない。

MERGE テーブルにデータを挿入するには、レコードの挿入先とするテーブルを INSERT_METHOD で指定する必要がある。 INSERT_METHOD は MERGE テーブルのみに使用できるオプションである。See 項7.2. 「MERGE テーブル」。このオプションは MySQL 4.0.0 で導入された。

作成されたテーブルでは、最初に PRIMARY キーが置かれ、続いてすべての UNIQUE キー、通常キーの順に配置される。そのため、MySQL オプティマイザで使用するキーを優先させることができ、また重複する UNIQUE キーをより迅速に検出できる。

DATA DIRECTORY='directory' または INDEX DIRECTORY='directory' を使用することによって、ストレージエンジンのデータファイルとインデックスファイルの格納場所を指定できる。注意: この directory には、対象のディレクトリのフルパス（相対パスではなく）を指定する。

これは、MySQL 4.0 において、--skip-symlink オプションは指定しないときの MyISAM テーブルに対してのみ機能する。 See 項5.6.1.2. 「Unix 上のテーブルに対するシンボリックリンクの使用」。