もし NULL か NOT NULL のどちらも指定されなければ、そのカラムは NULL が指定されたという形で扱われます。

整数カラムまたは浮動小数点カラムには、追加属性 AUTO_INCREMENT を含めることができます。インデックスされた AUTO_INCREMENT カラムに NULL (推奨) か 0 の値を挿入すると、カラムは次のシーケンス値に設定されます。通常これは、value が現在テーブルの中にあるカラムの最大値である、value+1 です。AUTO_INCREMENT シーケンスは 1 で始まります。

行の挿入後に AUTO_INCREMENT 値を検索するには、LAST_INSERT_ID() SQL 機能か mysql_insert_id() C API 関数を利用してください。項7.11.3. 「情報関数」、mysql_insert_id() を参照してください。

もし NO_AUTO_VALUE_ON_ZERO SQL モードが有効であれば、新しいシーケンス値を発生させずに 0 を AUTO_INCREMENT カラムに 0 として格納することができます。Server SQL Modes を参照してください。

MyISAM テーブルには、複合カラムキー内の AUTO_INCREMENT セカンダリカラムを指定することができます。項1.6.9. 「AUTO_INCREMENT の使用」 を参照してください。

MySQL 互換性がいくつかの ODBC アプリケーション持つために、次のクエリーを利用して、最後に挿入された行に AUTO_INCREMENT 値を見つけることができます。

SELECT * FROM tbl_name WHERE auto_col IS NULL

InnoDB と AUTO_INCREMENT の更なる情報に関しては、項9.4.3. 「InnoDB の AUTO_INCREMENT 処理」 を参照してください。

文字データ型 (CHAR、VARCHAR、TEXT) は、キャラクタセットとカラムの照合を指定するために CHARACTER SET と COLLATE 属性を含むことができます。詳細については、Character Set Supportをご参照ください。CHARSET は CHARACTER SET の同義語です。例 :

CREATE TABLE t (c CHAR(20) CHARACTER SET utf8 COLLATE utf8_bin);

MySQL 5.1 は、文字カラム定義内の長さ指定を文字数で解釈します。(MySQL 4.1 以前のバージョンでは、それらはバイトで解釈されます)。BINARY と VARBINARY の長さはバイトで表されています。

DEFAULT 節は、カラムのデフォルト値を指定します。例外がひとつあります。デフォルト値は一定でなければいけませんので、それは関数や式にはなり得ません。これはたとえば、日付カラムの値に NOW() や CURRENT_DATE のような関数の値をデフォルトとして設定することはできないという意味です。例外として、TIMESTAMP カラムのデフォルトとして CURRENT_TIMESTAMP を指定することができます。項6.3.1.1. 「TIMESTAMP の特性」 を参照してください。

もしカラム定義が明示的な DEFAULT 値を含まない場合、MySQL はデフォルト値を 項6.1.4. 「データ型デフォルト値」 のように規定します。

BLOB と TEXT カラムはデフォルト値として指定することができません。

厳密な SQL モードが有効になっていない場合でも、日付の値のデフォルトが NO_ZERO_IN_DATE の SQL モードに従っていない場合は、CREATE TABLE が失敗します。たとえば、c1 DATE DEFAULT '2010-00-00' を指定すると、CREATE TABLE が Invalid default value for 'c1' で失敗します。

MySQL Cluster NDB 7.1 以降でのネイティブなデフォルト値の処理.  MySQL Cluster NDB 7.1.0 からは、テーブルカラムのデフォルト値は、以前のように MySQL サーバーではなく、NDBCLUSTER によって格納されます。SQL ノードからデータノードに送信する必要のあるデータが少なくなるため、カラムのデフォルト値を持つテーブルへの挿入を以前より効率的に実行できます。

以前の MySQL Cluster リリースを使用して作成されたテーブルは MySQL Cluster 7.1.0 以降でも引き続き使用できますが、ネイティブなデフォルト値をサポートしていないため、アップグレードされるまでは MySQL サーバーによって指定されたデフォルト値を引き続き使用します。これは、オフラインの ALTER TABLE ステートメントを使用して実行できます。

MySQL Cluster NDB 7.1.0 以降で作成されたテーブルを、以前のバージョンの MySQL Cluster で使用することはできません。

ネイティブなデフォルト値をサポートする NDBCLUSTER テーブルは、MySQL サーバーによって課されるデフォルト値に関する制限に引き続き従います。詳細は 項6.1.4. 「データ型デフォルト値」 をご覧ください。

カラムのコメントは、COMMENT オプションを使用して、最大 255 文字の長さまで指定できます。コメントは SHOW CREATE TABLE と SHOW FULL COLUMNS ステートメントによって表示されます。

MySQL Cluster NDB 6.2.5 および MySQL Cluster NDB 6.3.2 からは、COLUMN_FORMAT を使用して、NDB テーブルの個々のカラムのデータストレージ形式を指定することもできます。許可されるカラム形式は、FIXED、DYNAMIC、および DEFAULT です。FIXED は固定幅ストレージを指定するために使用され、DYNAMIC はカラムを可変幅にできるようにします。また、DEFAULT は、カラムのデータ型に従って固定幅または可変幅のストレージが使用されるようにします (ROW_FORMAT 指定子によってオーバーライドされる可能性がある)。

NDB テーブルの場合、COLUMN_FORMAT のデフォルト値は DEFAULT です。

COLUMN_FORMAT は現在、NDB 以外のストレージエンジンを使用しているテーブルのカラムには影響を与えません。

NDB テーブルの場合、MySQL Cluster NDB 6.2.5 および MySQL Cluster NDB 6.3.2 からは、STORAGE 節を使用してカラムをディスク上またはメモリー内のどちらに格納するかを指定することもできます。STORAGE DISK を指定するとカラムはディスク上に格納され、STORAGE MEMORY を指定するとインメモリーストレージが使用されます。使用される CREATE TABLE ステートメントには、引き続き TABLESPACE 節を含める必要があります。

mysql> CREATE TABLE t1 (
    ->     c1 INT STORAGE DISK,
    ->     c2 INT STORAGE MEMORY
    -> ) ENGINE NDB;
ERROR 1005 (HY000): Can't create table 'c.t1' (errno: 140)

mysql> CREATE TABLE t1 (
    ->     c1 INT STORAGE DISK,
    ->     c2 INT STORAGE MEMORY
    -> ) TABLESPACE ts_1 ENGINE NDB;
Query OK, 0 rows affected (1.06 sec)

NDB テーブルの場合、STORAGE DEFAULT は STORAGE MEMORY と同等です。

STORAGE 節は、NDB 以外のストレージエンジンを使用しているテーブルには影響を与えません。

KEY は通常 INDEX の同義語です。キー属性 PRIMARY KEY はまた、カラム定義の中では単に KEY として指定できます。これは、互換性のためにほかのデータベースと共に利用されます。

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

PRIMARY KEY は、すべてのキーカラムを NOT NULL として定義する必要のある一意のインデックスです。もしそれらが NOT NULL として明示的に宣言されなければ、MySQL はそれらを暗示的に (そして静かに) 宣言します。1 つのテーブルは 1 つの PRIMARY KEY しか持つことができません。もし PRIMARY KEY がないのにアプリケーションがテーブル内で PRIMARY KEY を要求したら、MySQL は PRIMARY KEY として NULL カラムを持たない最初の UNIQUE インデックスを返します。

InnoDB テーブル内で長い PRIMARY KEY を持つとスペースを無駄に利用します。(詳しくは 項9.10. 「InnoDB テーブルとインデックス構造」 を参照してください。)

作成されたテーブルでは、PRIMARY KEY が最初に配置され、そのあとにすべての UNIQUE インデックス、さらに一意でないインデックスが続きます。このおかげで MySQL オプティマイザがどのインデックスを優先して利用するのか、また複製 UNIQUE キーをより早く検索するために役立ちます。

PRIMARY KEY は複合カラムインデックスになり得ます。しかし、カラム仕様内で PRIMARY KEY キー属性を利用して複合カラムインデックスを作成することはできません。それをしても、単一カラムが最初に来るという印が付けられるだけです。別々の PRIMARY KEY(index_col_name, ...) 節を利用しなければいけません。

PRIMARY KEY または UNIQUE インデックスが、整数型を含む 1 つのカラムのみで構成されている場合は、SELECT ステートメントでそのカラムを _rowid として参照することもできます。

MySQL 内では、PRIMARY KEY の名前は PRIMARY です。ほかのインデックスに関しては、もし名前を割り当てなければ、それを固有のものにするために任意のサフィックス (_2、_3、...) を利用して、最初にインデックスされたカラムと同じ名前に指定されます。SHOW INDEX FROM tbl_name を使用して、テーブルのインデックス名を確認できます。項8.5.5.23. 「SHOW INDEX 構文」 を参照してください。

いくつかのストレージエンジンでは、インデックスを作成するときに型を指定することができます。index_type 指定子の構文は USING type_name です。

例 :

CREATE TABLE lookup
  (id INT, INDEX USING BTREE (id))
  ENGINE = MEMORY;

MySQL 5.1.10 以前では、USING はインデックスカラムリストの前だけに与えることができました。5.1.10 での望ましい位置は、カラムリストの後ろです。このオプションをカラムリストの前で使用すると、将来の MySQL リリースでは認識されなくなります。

index_option 値はインデックスの追加オプションを指定します。USING はそのようなオプションの 1 つです。許容 index_option 値の詳細に関しては 項8.1.13. 「CREATE INDEX 構文」 を参照してください。

インデックスに関する更なる情報については、項4.4.4. 「MySQL におけるインデックスの使用」 を参照してください。

MySQL 5.1 では、MyISAM、InnoDB、および MEMORY ストレージエンジンのみが、NULL 値を含むことのできるカラム上のインデックスをサポートしています。それ以外の場合、インデックスされたカラムを NOT NULL として宣言しなければエラーが発生します。

CHAR、VARCHAR、BINARY、そして VARBINARY カラムには、インデックス接頭辞長を指定するために col_name(length) 構文を利用して、カラム値の最初に部分だけを利用するインデックスを作成することができます。また、BLOB および TEXT カラムもインデックス設定できますが、接頭辞長を指定する必要があります。接頭辞長は、バイナリ以外の文字列型の場合は文字数で、バイナリ列型の場合はバイト単位で指定されます。これは、インデックスエントリは CHAR、VARCHAR、そして TEXT カラムのそれぞれのカラム値の最初の length 文字で、そして BINARY、VARBINARY、そして BLOB カラムのそれぞれのカラム値の最初の length バイトで成り立っているということです。このようにカラム値の接頭辞だけをインデックスすることで、インデックスファイルをとても小さくすることができます。項4.4.2. 「カラムインデックス」 を参照してください。

MyISAM と InnoDB ストレージエンジンだけが BLOB と TEXT カラムのインデックスをサポートします。例 :

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

接頭辞は、最大 1000 バイトの長さ (InnoDB テーブルに対しては 767 バイト) まで可能です。接頭辞の制限がバイト単位で測定されるのに対して、CREATE TABLE ステートメントの接頭辞長は、バイナリ以外のデータ型 (CHAR、VARCHAR、TEXT) では文字数として解釈されることに注意してください。マルチバイトのキャラクタセットを利用するカラムの接頭辞長を指定するときにはこれを考慮に入れておいてください。

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

SELECT 内の TEXT か BLOB カラムに対して ORDER BY か GROUP BY を利用するとき、サーバーは max_sort_length システム変数によって指示された初期バイト数だけを利用して値をソートします。項6.4.3. 「BLOB と TEXT 型」 を参照してください。

フルテキスト検索に利用される特別な FULLTEXT インデックスを作成することができます。MyISAM ストレージエンジンだけが FULLTEXT インデックスをサポートします。それらは CHAR、VARCHAR、そして TEXT カラムからのみ作成することができます。インデックス設定は常に、カラム全体に対して実行されます。カラム接頭辞のインデックス設定はサポートされていないため、接頭辞長が指定されても無視されます。操作に関しての詳細は 項7.8. 「全文検索関数」 を参照してください。WITH PARSER 節は、もしフルテキストインデックスと検索操作が特別対応を必要とするなら、インデックスと共にパーサープラグインと提携するために index_option 値として指定することができます。この節は FULLTEXT インデックスだけに対して正当です。プラグインの作成に関しての詳細はThe MySQL Plugin API を参照してください。

空間データ型上に SPATIAL インデックスを作成することができます。空間型は MyISAM テーブルに対してだけサポートされており、インデックスされたカラムは NOT NULL として宣言されなければいけません。項7.13. 「空間拡張」 を参照してください。

InnoDB テーブルは外部キー制約の確認をサポートします。詳しくは章 9. InnoDB ストレージエンジンを参照してください。InnoDB の FOREIGN KEY 構文は、この節の最初に CREATE TABLE ステートメントに対して示した構文より制限が強いことに注意してください。参照されるテーブルのカラムは常に、明示的に指定される必要があります。InnoDB は、外部キーへの ON DELETE と ON UPDATE 作用の両方をサポートします。正確な構文に関しては、項9.4.4. 「FOREIGN KEY 制約」 を参照してください。

その他のストレージエンジンに関しては、MySQL サーバーは CREATE TABLE ステートメント内の FOREIGN KEY と REFERENCES 構文を検索し無視します。CHECK 節は、すべてのストレージエンジンに解析されますが、無視されます。Foreign Keys を参照してください。

テーブルあたり 4096 カラムという厳しい制限がありますが、特定のテーブルでは実効的な最大数が少なくなる可能性があります。最大数は The Maximum Number of Columns Per Table で説明されている要因に依存します。

AUTO_INCREMENT

テーブルの初期 AUTO_INCREMENT 値。MySQL 5.1 では、これは MyISAM、MEMORY、および InnoDB テーブルに対して機能します。また、MySQL 5.1.6 では ARCHIVE テーブルに対しても機能します。AUTO_INCREMENT テーブルオプションをサポートしていないエンジンに最初の自動インクリメント値を設定するには、テーブルを作成したあと、目的の値より 1 小さい値を持つ「ダミー」行を挿入してから、そのダミー行を削除します。

CREATE TABLE ステートメント内の AUTO_INCREMENT テーブルオプションをサポートするエンジンには、AUTO_INCREMENT 値をリセットするために ALTER TABLE tbl_name AUTO_INCREMENT = N を利用することもできます。その値は、現在カラム内にある最大値よりも小さく設定することはできません。

AVG_ROW_LENGTH

テーブルの平均行長近似値です。可変サイズ行を持つ大きいテーブルに対してのみ、これを設定する必要があります。

MyISAM テーブルを作成するとき、MySQL はテーブルが最終的にどの程度の大きさになるのかを決めるために MAX_ROWS と AVG_ROW_LENGTH オプションの製品を利用します。いずれのオプションも指定しない場合、MyISAM データおよびインデックスファイルの最大サイズは、デフォルトで 256TB になります。(もし使用している OS がその大きさのファイルをサポートしていなければ、テーブルサイズはファイルサイズ制限に制約されます)。もし大きいファイルが必要無く、インデックスを小さく早くするためにポインタサイズを小さくしたければ、myisam_data_pointer_size システム変数を設定することでデフォルトのポインタサイズを小さくすることができます。詳細は、Server System Variables を参照してください。) もしすべてのテーブルをデフォルトの制限よりも大きくすることを希望し、必要以上にテーブルが遅く、大きくなっても良いのであれば、この変数を設定することでデフォルトのポインタサイズを増やすことができます。この値を 7 に設定すると、テーブルサイズが最大 65,536TB まで可能になります。

[DEFAULT] CHARACTER SET

テーブルにデフォルトキャラクタセットを指定します。CHARSET は CHARACTER SET の同義語です。キャラクタセット名が DEFAULT の場合は、データベースのキャラクタセットが使用されます。

CHECKSUM

MySQL で、すべての行についてライブチェックサム (つまり、テーブルの変更時に MySQL が自動的に更新するチェックサム) が保持されるようにする場合は、この値を 1 に設定します。これはテーブルの更新スピードを少し遅くしますが、壊れたテーブルを見つけるのが早くなります。CHECKSUM TABLE ステートメントはチェックサムをリポートします。(MyISAM のみ。)

[DEFAULT] COLLATE

テーブルにデフォルト照合を指定します。

COMMENT

最高 60 文字のテーブルに対するコメントです。

CONNECTION

FEDERATED テーブルの接続文字列です。

DATA DIRECTORY、INDEX DIRECTORY

DATA DIRECTORY='directory' か INDEX DIRECTORY='directory' を利用することで、MyISAM ストレージエンジンがテーブルのデータファイルとインデックスファイルをどこに置く必要があるのかを指定することができます。ディレクトリは、ディレクトリへの (相対パスではなく) フルパス名である必要があります。

これらのオプションは --skip-symbolic-links オプションを利用していないときだけ機能します。OS にはまた、有効なスレッドセーフな realpath() コールがなければいけません。詳細については、項4.6.1.2. 「Unix 上のテーブルに対するシンボリックリンクの使用」 をご参照ください。

MyISAM テーブルが DATA DIRECTORY オプションなしで作成されている場合、.MYD ファイルはデータベースディレクトリ内に作成されます。このとき、MyISAM によって既存の .MYD ファイルが検索された場合、デフォルトではそのファイルが上書きされます。同じことが、INDEX DIRECTORY オプションなしで作成されたテーブルの .MYI ファイルにも言えます。MySQL 5.1.23 では、この動作を抑制するには --keep_files_on_create オプションを使用してサーバーを起動します。この場合は、MyISAM によって既存のファイルが上書きされず、代わりにエラーが返されます。

MyISAM テーブルが DATA DIRECTORY または INDEX DIRECTORY オプションを使用して作成されており、既存の .MYD または .MYI ファイルが見つかった場合、MyISAM は常にエラーを返します。指定されたディレクトリ内のファイルは上書きされません。

DELAY_KEY_WRITE

キー更新をテーブルが閉じられるときまで遅らせたければこれを 1 に設定してください。Server System Variables 内の delay_key_write システム変数についての説明を参照してください。(MyISAM のみ。)

INSERT_METHOD

もしデータを MERGE テーブルに挿入したければ、その行が挿入されるべきテーブルの INSERT_METHOD を利用して指定する必要があります。INSERT_METHOD は MERGE テーブルにのみ有効なオプションです。最初か最後のテーブルに挿入するためには FIRST か LAST 値を、また挿入を防ぐためには NO 値を利用してください。章 10. MERGE ストレージエンジン を参照してください。

KEY_BLOCK_SIZE

このオプションは、インデックスキーブロックに使用するバイト単位のサイズに関して、ストレージエンジンにヒントを提供します。このエンジンは必要に応じて値を変更することが可能です。0 という値は、デフォルト値を利用しなければいけないということを表しています。テーブル値を無効にするために、個々のインデックス定義はそれ自身の KEY_BLOCK_SIZE 値を指定することができます。KEY_BLOCK_SIZE は MySQL 5.1.10 で追加されました。

MAX_ROWS

テーブル内に格納する予定の最大行数。これは、厳しい制限というよりは、ストレージエンジンに対して、テーブルが少なくともこの程度の行数を格納できる必要があるということを表すヒントのようなものです。

MIN_ROWS

テーブル内に格納する予定の最小行数MEMORY ストレージエンジンは、このオプションをメモリーの使用に関するヒントとして使用します。

PACK_KEYS

PACK_KEYS は MyISAM テーブルとだけ効果を発揮します。小さいインデックスを持ちたければ、このオプションを 1 に設定してください。これは通常更新スピードを遅くし、読み込みを早くします。オプションを 0 に設定すると、すべてのキーパッキングが無効になります。このオプションを DEFAULT に設定すると、長い CHAR、VARCHAR、BINARY、または VARBINARY カラムのみをパックするようストレージエンジンに指示します。

もし PACK_KEYS を利用しなければ、デフォルトでは文字列をパックしますが、数字はパックしません。もし PACK_KEYS=1 を利用すると、数字もパックされます。

バイナリ数値キーをパックするとき、MySQL は接頭辞圧縮を利用します。

これは、もし 2 つの連続した行上に複数の同等なキーを持っていたら、すべての後続する 「同じ」 キーは通常 2 バイトしか利用しないということを意味します。(行のポインタを含む) これを、後続キーが storage_size_for_key + pointer_size を取る通常のケースと比べてみてください。(ポインタサイズは通常 4) 反対に、同じ数値を多く持つ場合のみ、接頭辞圧縮の恩恵を多いに受けることができます。もしすべてのキーがまったく異なり、NULL 値を持つことができるキーでなければ、1 つのキーに対してもう 1 バイト多く利用することになります。(この場合、もしキーが NULL であれば、パックされたキー長はマークするために利用されたものと同じバイト数で格納されます)。

PASSWORD

このオプションは使用されません。.frm ファイルを暗号化してほかの MySQL サーバーで使用できないようにする必要がある場合は、当社の販売部門に問い合わせてください。

RAID_TYPE

RAID のサポートは、MySQL 5.0 で削除されています。RAID については、CREATE TABLE Syntax を参照してください。

ROW_FORMAT

行がどのように格納されるべきかを定義します。MyISAM テーブルに対しては、静的、または可変長行フォーマットのオプション値は FIXED か DYNAMIC になり得ます。myisampack は型を COMPRESSED に設定します。MyISAM Table Storage Formats を参照してください。

InnoDB テーブルに対しては、行はデフォルトでコンパクトフォーマットに格納されます。旧バージョンの MySQL で使用されていた非圧縮形式は、ROW_FORMAT=REDUNDANT を指定することによって引き続き要求できます。

UNION

UNION は、同一の MyISAM テーブルの集まりを 1 つのものとしてアクセスしたいときに利用することができます。これは MERGE テーブルとのみ機能します。章 10. MERGE ストレージエンジン を参照してください。

MERGE テーブルにマップするテーブルに、SELECT、UPDATE、そして DELETE 権限を持たなければいけません。

HASH(expr):行を置くためのキーを作成するために 1 つ、または複数のカラムをハッシュします。expr は 1 つ、または複数のテーブルカラムを利用する式です。これは、単一整数値を生む正当な MySQL 式 (MySQL 関数を含む) であればどれでもよいです。たとえば、これらはすべて PARTITION BY HASH を利用した有効な CREATE TABLE ステートメントです。

CREATE TABLE t1 (col1 INT, col2 CHAR(5))
    PARTITION BY HASH(col1);

CREATE TABLE t1 (col1 INT, col2 CHAR(5))
    PARTITION BY HASH( ORD(col2) );

CREATE TABLE t1 (col1 INT, col2 CHAR(5), col3 DATETIME)
    PARTITION BY HASH ( YEAR(col3) );

PARTITION BY HASH と、VALUES LESS THAN や VALUES IN 節は一緒に利用しません。

PARTITION BY HASH はパーティション数によって分割された (モジュール)expr の残りを利用します。追加情報については HASH Partitioning を参照してください。

LINEAR キーワードは異なるアルゴリズムを若干必要とします。l この場合、行が格納されるパーティション数は、1 つ、または複数の論理的な AND 操作の結果計算されます。線形ハッシングについての説明と例に関しては、LINEAR HASH Partitioning を参照してください。

KEY(column_list):MySQL がハッシング機能を均等なデータ分布を保障するために提供するという事以外、これは HASH と似ています。column_list 引数は単にテーブルカラムのリストです。この例は、キーによって 4 つのパーティションに分割された単純なテーブルを表しています。

CREATE TABLE tk (col1 INT, col2 CHAR(5), col3 DATE)
    PARTITION BY KEY(col3)
    PARTITIONS 4;

キーによって分割されたテーブルには、LINEAR キーワードを利用した線形分割を採用することができます。これは HASH によって分割されたテーブルと同じ効果を持ちます。これは、分割数はモジュールではなく & 演算子を利用して求められるということを意味します。(詳細に関しては LINEAR HASH Partitioning、と KEY Partitioning を参照してください)。この例は、5 つのパーティション間でデータを分布するためにキーによる線形分割を利用しています。

CREATE TABLE tk (col1 INT, col2 CHAR(5), col3 DATE)
    PARTITION BY LINEAR KEY(col3)
    PARTITIONS 5;

PARTITION BY KEY と、VALUES LESS THAN や VALUES IN 節は一緒に利用しません。

RANGE:この場合、expr は VALUES LESS THAN 演算子のセットを利用して値の範囲を表します。範囲の分割を利用するとき、VALUES LESS THAN を利用して最低 1 つのパーティションを定義する必要があります。VALUES IN を範囲の分割に利用することはできません。

VALUES LESS THAN はリテラル値、または単一値を評価する式のどちらかと一緒に利用することができます。

次のスキーマに従って、年の値を含むカラム上でパーティション化するテーブルがあるとします。

そのような分割スキーマを実施するテーブルはここに表されている CREATE TABLE ステートメントによって実現されます。

CREATE TABLE t1 (
    year_col  INT,
    some_data INT
)
PARTITION BY RANGE (year_col) (
    PARTITION p0 VALUES LESS THAN (1991),
    PARTITION p1 VALUES LESS THAN (1995),
    PARTITION p2 VALUES LESS THAN (1999),
    PARTITION p3 VALUES LESS THAN (2002),
    PARTITION p4 VALUES LESS THAN (2006),
    PARTITION p5 VALUES LESS THAN MAXVALUE
);

PARTITION ... VALUES LESS THAN ... ステートメントは連続法で機能します。VALUES LESS THAN MAXVALUE は、指示されないかぎり、最大値よりも大きい 「leftover」 値を指定するために機能します。

VALUES LESS THAN 節は switch ... case ブロックの case 部分と似た方法で連続的に機能するということを覚えて置いてください。(C、Java、そして PHP 等のような多くのプログラム言語内で見られるのと同じように)これは、それぞれの連続した VALUES LESS THAN 内で指定された上限はその前のものよりも大きく、MAXVALUE に参照を付けるものがリストの一番最後に来るという方法で節を配列しなければいけない、ということを意味します。

LIST(expr):これは州や国のコードなどのような、制限された値のセットを持つテーブルカラムに基づいたパーティションを割り当てるときに便利です。このような場合、特定の州や国に関係している行を 1 つのパーティションに指定したり、または、特定の州や国のセットに対してパーティションを用意しておくことができます。これは、VALUES IN だけが各パーティションに許容値を指定するのに利用されるということを除いて、RANGE と似ています。

VALUES IN はマッチする値のリストと共に利用されます。たとえば、次のように分割スキーマを作成することができます。

CREATE TABLE client_firms (
    id   INT,
    name VARCHAR(35)
)
PARTITION BY LIST (id) (
    PARTITION r0 VALUES IN (1, 5, 9, 13, 17, 21),
    PARTITION r1 VALUES IN (2, 6, 10, 14, 18, 22),
    PARTITION r2 VALUES IN (3, 7, 11, 15, 19, 23),
    PARTITION r3 VALUES IN (4, 8, 12, 16, 20, 24)
);

リストの分割を利用するとき、VALUES IN を利用して最低 1 つのパーティションを定義する必要があります。VALUES LESS THAN を PARTITION BY LIST と一緒に利用することはできません。

パーティションは、num がパーティション数である PARTITIONS num 節を利用して任意に指定されます。この節、そして PARTITION 節が両方利用されたら、num は PARTITION 節を利用して宣言されたパーティションの合計数と同一でなければいけません。

パーティションは任意でサブパーティションに分解することもあります。これは任意の SUBPARTITION BY 節を利用して指示することができます。サブパーティションは HASH か KEY によって行われるでしょう。これらのどちらかは LINEAR でしょう。これらは、すでに説明された同等な分割の型と同じように機能します。LIST や RANGE でサブパーティションするのは不可能です)。

整数値が後に続く SUBPARTITIONS キーワードを利用してサブパーティション数を指示することができます。

MySQL 5.1.12 で、PARTITIONS や SUBPARTITIONS 節で利用された値の厳密な確認を紹介しています。このバージョンから、この値は次の規則を遵守します。

PARTITION partition_name:これはパーティションの論理名を指定します。

VALUES 節:範囲の分割に関しては、各パーティションが VALUES LESS THAN 節を含む必要があり、リストの分割に関しては、各パーティションに対して VALUES IN 節を指定する必要があります。これは、どの行がこのパーティションに格納されるのかということを決めるために利用されます。構文例に関しては、Partitioning のパーティション型に関する説明を参照してください。

パーティションを説明する文字列を指定するために、オプションの COMMENT 節を使用できます。例 :

COMMENT = 'Data for the years previous to 1999'

DATA DIRECTORY と INDEX DIRECTORY は、このパーティションのデータとインデックスがそれぞれどこに格納されるのかを指示するために利用されます。data_dir と index_dir はどちらも、絶対システムパス名である必要があります。例 :

CREATE TABLE th (id INT, name VARCHAR(30), adate DATE)
PARTITION BY LIST(YEAR(adate))
(
  PARTITION p1999 VALUES IN (1995, 1999, 2003)
    DATA DIRECTORY = '/var/appdata/95/data'
    INDEX DIRECTORY = '/var/appdata/95/idx',
  PARTITION p2000 VALUES IN (1996, 2000, 2004)
    DATA DIRECTORY = '/var/appdata/96/data'
    INDEX DIRECTORY = '/var/appdata/96/idx',
  PARTITION p2001 VALUES IN (1997, 2001, 2005)
    DATA DIRECTORY = '/var/appdata/97/data'
    INDEX DIRECTORY = '/var/appdata/97/idx',
  PARTITION p2000 VALUES IN (1998, 2002, 2006)
    DATA DIRECTORY = '/var/appdata/98/data'
    INDEX DIRECTORY = '/var/appdata/98/idx'
);

DATA DIRECTORY と INDEX DIRECTORY は、MyISAM テーブルで利用される CREATE TABLE ステートメントの table_option 節と同じ形で機能します。

各パーティションには、1 つのデータディレクトリとインデックスディレクトリが指定されます。指定されない場合、データとインデックスは、デフォルトでテーブルのデータベースディレクトリに格納されます。

Windows では、DATA DIRECTORY および INDEX DIRECTORY オプションは個々のパーティションまたはサブパーティションに対してサポートされていません。MySQL 5.1.24 からは、警告が生成される点を除き、これらのオプションは Windows では無視されます。(Bug#30459)

パーティション内に格納する行の最大、最小数をそれぞれ指定するために MAX_ROWS と MIN_ROWS が利用されます。max_number_of_rows と min_number_of_rows の値は正整数でなければいけません。同名のテーブルレベルオプションと同様に、これらはサーバーに対してただの 「提案」 として機能し、厳しい制限ではありません。

任意の TABLESPACE 節は、パーティションのテーブル領域を指定するのに利用されるでしょう。MySQL クラスタにのみ利用されます。

パーティション分割ハンドラは、PARTITION と SUBPARTITION の両方について [STORAGE] ENGINE オプションを受け入れます。現在、この方法は、すべてのパーティションまたはすべてのサブパーティションを同じストレージエンジンに設定する場合にしか使用できず、同じテーブル内のパーティションまたはサブパーティションに異なるストレージエンジンを設定しようとするとエラーが発生します。 ERROR 1469 (HY000): The mix of handlers in the partitions is not allowed in this version of MySQL. 将来の MySQL リリースでは、パーティション分割に関するこの制限を取り除く予定です。

NODEGROUP オプションは node_group_id によって確認されたノードグループの一部としてこのパーティションを機能させるために利用できます。このオプションは MySQL クラスタに対してだけ利用可能です。

パーティション定義は、1 つかそれ以上の subpartition_definition 節を含みます。これらはそれぞれ、name が識別子のサブパーティションである SUBPARTITION name の最小値で構成されます。SUBPARTITION を利用した PARTITION キーワードの入れ替え以外は、サブパーティション定義の構文はパーティション定義の構文と同一です。

サブパーティションは HASH か KEY によって行われなけれる必要があり、そして RANGE か LIST パーティション上のみで行われます。Subpartitioning を参照してください。

CREATE TABLE 部分で指定されているテーブル定義は無視されます。その定義が既存のテーブルの定義に一致しない場合でも、エラーは発生しません。

テーブル内のカラム数と、SELECT 部分によって生成されたカラム数の間に不一致がある場合、選択された値は右端のカラムに割り当てられます。たとえば、テーブルに n カラムが含まれていて、SELECT によって m カラムが生成された場合 (ここで、m < n)、選択された値はテーブル内の右端の m 個のカラムに割り当てられます。 最初の n – m カラムにはそれぞれ、カラム定義で明示的に指定されたデフォルト値か、またはカラム定義にデフォルト値が含まれていない場合はカラムデータ型の暗黙のデフォルト値の、いずれかのデフォルト値が割り当てられます。

厳密な SQL モードが有効になっていて、これらの最初のいずれかのカラムに明示的なデフォルト値が含まれていない場合は、ステートメントがエラーで失敗します。