もし 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 関数を利用してください。項11.10.3. 「情報関数」、項23.2.3.37. 「mysql_insert_id()」 を参照して下さい。

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

注意:各テーブルに AUTO_INCREMENT カラムは1つだけ存在する事ができ、それはインデックスされる必要があり、DEFAULT 値を持つ事はできません。AUTO_INCREMENT カラムは正数のみを含んでいる時だけ正しく機能します。負数を挿入すると、とても大きな正数を挿入したと解釈されます。これは、数字が正数から負数に 「ラップ」 される時の精度の問題を避ける為に、また 0 を含む AUTO_INCREMENT カラムを誤って採用してしまわない為に行われます。

MyISAM テーブルには、複合カラム キー内の AUTO_INCREMENT セカンダリ カラムを指定する事ができます。詳しくは Using AUTO_INCREMENT を参照してください。

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

SELECT * FROM tbl_name WHERE auto_col IS NULL

InnoDB と AUTO_INCREMENT の更なる情報に関しては、項13.5.6.3. 「AUTO_INCREMENT カラムが InnoDB 内でどのように機能するか」 を参照してください。

SERIAL 属性は BIGINT UNSIGNED NOT NULL AUTO_INCREMENT UNIQUE のエイリアスです。

文字データタイプ(CHAR、VARCHAR、TEXT)は、文字セットとカラムの照合を指定する為にCHARACTER SET と COLLATE 属性を含む事ができます。詳細に関しては 章 9. キャラクタセットサポート を参照して下さい。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 を指定する事ができます。詳しくは 項10.3.1.1. 「TIMESTAMP MySQL 4.1での性質」 を参照してください。

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

BLOB と TEXT カラムはデフォルト値として割り当てる事ができません。

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

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 を持つとスペースを無駄に利用します。（詳しくは 項13.5.13. 「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 を利用してテーブルのインデックス名を調べる事ができます。詳しくは 項12.5.4.17. 「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 5.3 以降は、カラム リストの前でのオプションの使用は見られません。

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

インデックスに関する更なる情報については、項6.4.5. 「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 バイトで成り立っているという事です。このようにカラム値のプリフィックスだけをインデックスする事で、インデックス ファイルをとても小さくする事ができます。詳しくは 項6.4.3. 「カラムインデックス」 を参照してください。

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

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

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

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

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

フル テキスト検索に利用される特別な FULLTEXT インデックスを作成する事ができます。MyISAM ストレージ エンジンだけが FULLTEXT インデックスをサポートします。それらは CHAR、 VARCHAR、そして TEXT カラムからのみ作成する事ができます。インデックスする作業は必ずカラム全体に対して行われますので、部分的インデックスはサポートされておらず、プリフィックス長を指定しても無視されます。操作に関しての詳細は 項11.7. 「全文検索関数」 を参照してください。WITH PARSER 条項は、もしフル テキスト インデックスと検索操作が特別対応を必要とするなら、インデックスと共にパーサー プラグインと提携する為に index_option 値として指定する事ができます。この条項は FULLTEXT インデックスだけに対して正当です。プラグインの作成に関しての詳細は項25.2. 「The MySQL Plugin Interface」 を参照してください。

空間データ タイプ上に SPATIAL インデックスを作成する事ができます。空間タイプは MyISAM テーブルに対してだけサポートされており、インデックスされたカラムは NOT NULL として宣言されなければいけません。詳しくは 章 16. Spatial Extensions を参照してください。

InnoDB テーブルは外部キー制約のチェックをサポートします。詳しくは 項13.5. 「InnoDB ストレージ エンジン」 を参照してください。InnoDB 内の FOREIGN KEY 構文は、このセクションの最初でCREATE TABLE ステートメントの為に紹介された構文よりも制限的である事を覚えておいてください。参照テーブルのカラムは必ず明確に名前を付けられる必要があります。InnoDB は、外部キーへの ON DELETE と ON UPDATE 作用の両方をサポートします。正確な構文に関しては、項13.5.6.4. 「FOREIGN KEY 制約」 を参照してください。

その他のストレージ エンジンに関しては、MySQL サーバは CREATE TABLE ステートメント内の FOREIGN KEY と REFERENCES 構文を検索し無視します。CHECK 条項は、全てのストレージ エンジンに解析されますが、無視されます。詳しくは 項1.8.5.5. 「外部キー」 を参照してください。

MyISAM テーブルに対しては、各 NULL カラムは1ビット余分に利用し、一番近いバイト数に丸められます。バイトでの最大行長は次のように計算されます。

row length = 1
             + (sum of column lengths)
             + (number of NULL columns + delete_flag + 7)/8
             + (number of variable-length columns)

delete_flag は静的行フォーマットのテーブルに対しては1です。静的テーブルは、行が削除されたかどうか指示するフラッグに対して行レコード内でビットを利用します。 delete_flag は、フラッグがダイナミック行ヘッダー内で格納される為、ダイナミック テーブルに対しては0です。

これらの計算は、NULL カラムと NOT NULL カラムの格納サイズが同じである InnoDB テーブルには適応しません。

AUTO_INCREMENT

テーブルの初期 AUTO_INCREMENT 値。MySQL 5.1 では、これは MyISAM、MEMORY、そして InnoDB テーブルに対して機能します。これはまた、MySQL 5.1.6 以降も ARCHIVE テーブルに対しても機能します。 AUTO_INCREMENT テーブル オプションをサポートしないエンジンに最初の自動インクリメント値を設定する為に、テーブルを作成した後、求められる値よりの1少ない値の 「dummy」 行を挿入し、その後ダミー行を削除してください。

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

AVG_ROW_LENGTH

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

MyISAM テーブルを作成する時、MySQL はテーブルが最終的にどの程度の大きさになるのかを決める為に MAX_ROWS と AVG_ROW_LENGTH オプションの製品を利用します。もしどちらのオプションも指定しなければ、テーブルの最大サイズはデフォルトで256 TB になります。(もし使用している OS がその大きさのファイルをサポートしていなければ、テーブル サイズはファイル サイズ制限に制約されます。)もし大きいファイルが必要無く、インデックスを小さく早くする為にポインタサイズを小さくしたければ、myisam_data_pointer_size システム変数を設定する事でデフォルトのポインタ サイズを小さくする事ができます。（詳しくは 項4.2.3. 「システム変数」 をご確認ください。）もし全てのテーブルをデフォルトの制限よりも大きくする事を希望し、必要以上にテーブルが遅く、大きくなっても良いのであれば、この変数を設定する事でデフォルトのポインタサイズを増やす事ができます。

[DEFAULT] CHARACTER SET

テーブルにデフォルト文字セットを指定します。CHARSET は CHARACTER SET の同義語です。

CHECKSUM

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

COLLATE

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

COMMENT

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

CONNECTION

FEDERATED テーブルの接続文字列です。(注意:MySQL の古いバージョンは COMMENT オプションを接続文字列に利用していました。)

DATA DIRECTORY、INDEX DIRECTORY

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

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

DELAY_KEY_WRITE

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

INSERT_METHOD

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

KEY_BLOCK_SIZE

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

MAX_ROWS

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

MIN_ROWS

テーブル内に格納する予定の最小行数

PACK_KEYS

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

もし 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 の情報に関しては、http://dev.mysql.com/doc/refman/4.1/en/create-table.html を参照してください。

ROW_FORMAT

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

InnoDB テーブルに対しては、行はデフォルトでコンパクト フォーマットに格納されます。(ROW_FORMAT=COMPACT)ROW_FORMAT=REDUNDANT を指定する事により、MySQL の古いバージョンで利用される非コンパクト フォーマットをリクエストする事もできます。

UNION

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

MERGE テーブルにマップするテーブルに、SELECT、UPDATE、そして DELETE 権限を持たなければいけません。(注意:以前は、全てのテーブルは、MERGE テーブルそのものと同じデータベース内にある必要がありました。この制限はもう適応されません。)

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 の残りを利用します。追加情報については 項15.2.3. 「HASH パーティショニング」 を参照してください。

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

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 によって分割されたテーブルと同じ効果を持ちます。これは、分割数はモジュールではなく & 演算子を利用して求められるという事を意味します。(詳細に関しては 項15.2.3.1. 「LINEAR HASH パーティショニング」、と 項15.2.4. 「KEY パーティショニング」 を参照してください。)この例は、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 と一緒に利用する事はできません。

注意:現在は、VALUES IN と共に利用される値のリストは整数値のみで構成されています。

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

注意:RANGE か LIST によって領域確保されたテーブルを作成するのに PARTITIONS 条項を利用したかどうかに関わらず、テーブル定義の中に最低1つ以上の PARTITION VALUES 条項を含む必要があります。(下記参照)

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

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

MySQL 5.1.12 で、PARTITIONS や SUBPARTITIONS 条項で利用された値の厳密なチェックを紹介しています。このバージョンから、この値は次のルールを遵守します。

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

VALUES 条項:範囲の領域確保に関しては、各パーティションが VALUES LESS THAN 条項を含む必要があり、リストの領域確保に関しては、各パーティションに対して VALUES IN 条項を指定する必要があります。これは、どの行がこのパーティションに格納されるのかという事を決める為に利用されます。構文例に関しては、章 15. パーティショニング のパーティション タイプに関する説明を参照してください。

任意の COMMENT 条項はパーティションを説明する為に利用されるでしょう。.このコメントは単一引用句で始まらなければいけません。例:

COMMENT = 'Data for the years previous to 1999'

DATA DIRECTORY と INDEX DIRECTORY は、このパーティションのデータとインデックスがそれぞれどこに格納されるのかを指示する為に利用されます。data_dir to 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つのデータ ディレクトリとインデックス ディレクトリが指定されます。もし指定されなければ、データとインデックスはデフォルトで MySQL データ ディレクトリに格納されます。

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

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

任意の [STORAGE] ENGINE 条項は、この MySQL サーバにサポートされたエンジンであるこのパーティション内のテーブルが、指定されたストレージ エンジンを利用するように機能します。STORAGE キーワードとイコールのサイン(=) の両方は任意です。もしこのオプションを利用して、パーティションを特定するストレージ エンジンが設定されなければ、テーブル全体に適応するエンジンがこのパーティションで利用されます。

注意:領域確保ハンドラは PARTITION と SUBPARTITION の両方に対して [STORAGE] ENGINE オプションを受け入れます。現在これを利用する唯一の方法は、全てのパーティション、サブ パーティションを同じストレージ エンジンに設定する事です。もし同じテーブル内で、パーティション、サブ パーティションに異なるストレージ エンジンを設定しようとするとエラーが発生します。エラー 1469 (HY000): MySQL のこのバージョンではパーティション内でハンドラを混在させる事は許可されていません。. 将来の MySQL 5.1 リリース時には、領域確保に関するこの制限を取り除く予定です。

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

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

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