MySQL :: MySQL 8.0 リファレンスマニュアル :: 13.1.20 CREATE TABLE ステートメント

9.1 English
9.0 English
8.4 English
8.0 English
5.7 English

MySQL 8.0 リファレンスマニュアル / ... / CREATE TABLE ステートメント

このページは機械翻訳したものです。

13.1.20 CREATE TABLE ステートメント

13.1.20.1 CREATE TABLE によって作成されるファイル
13.1.20.2 CREATE TEMPORARY TABLE ステートメント
13.1.20.3 CREATE TABLE ... LIKE ステートメント
13.1.20.4 CREATE TABLE ... SELECT ステートメント
13.1.20.5 FOREIGN KEY の制約
13.1.20.6 CHECK 制約
13.1.20.7 暗黙のカラム指定の変更
13.1.20.8 CREATE TABLE および生成されるカラム
13.1.20.9 セカンダリインデックスと生成されたカラム
13.1.20.10 非表示カラム
13.1.20.11 NDB_TABLE オプションの設定

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

CREATE [TEMPORARY] TABLE [IF NOT EXISTS] tbl_name
    [(create_definition,...)]
    [table_options]
    [partition_options]
    [IGNORE | REPLACE]
    [AS] query_expression

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

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

column_definition: {
    data_type [NOT NULL | NULL] [DEFAULT {literal | (expr)} ]
      [VISIBLE | INVISIBLE]
      [AUTO_INCREMENT] [UNIQUE [KEY]] [[PRIMARY] KEY]
      [COMMENT 'string']
      [COLLATE collation_name]
      [COLUMN_FORMAT {FIXED | DYNAMIC | DEFAULT}]
      [ENGINE_ATTRIBUTE [=] 'string']
      [SECONDARY_ENGINE_ATTRIBUTE [=] 'string']
      [STORAGE {DISK | MEMORY}]
      [reference_definition]
      [check_constraint_definition]
  | data_type
      [COLLATE collation_name]
      [GENERATED ALWAYS] AS (expr)
      [VIRTUAL | STORED] [NOT NULL | NULL]
      [VISIBLE | INVISIBLE]
      [UNIQUE [KEY]] [[PRIMARY] KEY]
      [COMMENT 'string']
      [reference_definition]
      [check_constraint_definition]
}

data_type:
    (see 第11章「データ型」)

key_part: {col_name [(length)] | (expr)} [ASC | DESC]

index_type:
    USING {BTREE | HASH}

index_option: {
    KEY_BLOCK_SIZE [=] value
  | index_type
  | WITH PARSER parser_name
  | COMMENT 'string'
  | {VISIBLE | INVISIBLE}
  |ENGINE_ATTRIBUTE [=] 'string'
  |SECONDARY_ENGINE_ATTRIBUTE [=] 'string'
}

check_constraint_definition:
    [CONSTRAINT [symbol]] CHECK (expr) [[NOT] ENFORCED]

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

reference_option:
    RESTRICT | CASCADE | SET NULL | NO ACTION | SET DEFAULT

table_options:
    table_option [[,] table_option] ...

table_option: {
    AUTOEXTEND_SIZE [=] value
  | AUTO_INCREMENT [=] value
  | AVG_ROW_LENGTH [=] value
  | [DEFAULT] CHARACTER SET [=] charset_name
  | CHECKSUM [=] {0 | 1}
  | [DEFAULT] COLLATE [=] collation_name
  | COMMENT [=] 'string'
  | COMPRESSION [=] {'ZLIB' | 'LZ4' | 'NONE'}
  | CONNECTION [=] 'connect_string'
  | {DATA | INDEX} DIRECTORY [=] 'absolute path to directory'
  | DELAY_KEY_WRITE [=] {0 | 1}
  | ENCRYPTION [=] {'Y' | 'N'}
  | ENGINE [=] engine_name
  | ENGINE_ATTRIBUTE [=] 'string'
  | 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}
  | SECONDARY_ENGINE_ATTRIBUTE [=] 'string'
  | STATS_AUTO_RECALC [=] {DEFAULT | 0 | 1}
  | STATS_PERSISTENT [=] {DEFAULT | 0 | 1}
  | STATS_SAMPLE_PAGES [=] value
  | TABLESPACE tablespace_name [STORAGE {DISK | MEMORY}]
  | UNION [=] (tbl_name[,tbl_name]...)
}

partition_options:
    PARTITION BY
        { [LINEAR] HASH(expr)
        | [LINEAR] KEY [ALGORITHM={1 | 2}] (column_list)
        | RANGE{(expr) | COLUMNS(column_list)}
        | LIST{(expr) | COLUMNS(column_list)} }
    [PARTITIONS num]
    [SUBPARTITION BY
        { [LINEAR] HASH(expr)
        | [LINEAR] KEY [ALGORITHM={1 | 2}] (column_list) }
      [SUBPARTITIONS num]
    ]
    [(partition_definition [, partition_definition] ...)]

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

subpartition_definition:
    SUBPARTITION logical_name
        [[STORAGE] ENGINE [=] engine_name]
        [COMMENT [=] 'string' ]
        [DATA DIRECTORY [=] 'data_dir']
        [INDEX DIRECTORY [=] 'index_dir']
        [MAX_ROWS [=] max_number_of_rows]
        [MIN_ROWS [=] min_number_of_rows]
        [TABLESPACE [=] tablespace_name]

query_expression:
    SELECT ...   (Some valid select or union statement)

CREATE TABLE は、指定された名前を持つテーブルを作成します。このテーブルに対する CREATE 権限が必要です。

デフォルトでは、テーブルは InnoDB ストレージエンジンを使用してデフォルトデータベースに作成されます。テーブルがすでに存在する場合、デフォルトデータベースが存在しない場合、またはデータベースが存在しない場合はエラーが発生します。

MySQL にはテーブル数の制限はありません。ベースとなるファイルシステムによっては、テーブルを表すファイル数に制限がある場合があります。個々のストレージエンジンには、エンジン固有の制約が課される場合があります。 InnoDB では、最大 40 億個のテーブルを使用できます。

テーブルの物理表現の詳細は、セクション13.1.20.1「CREATE TABLE によって作成されるファイル」を参照してください。

このセクションの次のトピックで説明するように、CREATE TABLE ステートメントにはいくつかの側面があります:

テーブル名

tbl_name

特定のデータベース内にテーブルを作成するには、テーブル名を db_name.tbl_name として指定できます。そのデータベースが存在すると仮定すると、これは、デフォルトデータベースが存在するかどうかには関係なく機能します。引用符で囲まれた識別子を使用する場合は、データベース名とテーブル名を個別に引用符で囲みます。たとえば、`mydb.mytbl` ではなく、`mydb`.`mytbl` と記述します。

許可されるテーブル名のルールは、セクション9.2「スキーマオブジェクト名」に示されています。
IF NOT EXISTS

テーブルが存在する場合にエラーが発生しないようにします。ただし、既存のテーブルの構造が CREATE TABLE ステートメントによって示されている構造と同一であることの検証は行われません。

一時テーブル

テーブルの作成時に TEMPORARY キーワードを使用できます。 TEMPORARY テーブルは現在のセッション内でのみ表示され、セッションがクローズされると自動的に削除されます。詳細は、セクション13.1.20.2「CREATE TEMPORARY TABLE ステートメント」を参照してください。

テーブルのクローニングおよびコピー

LIKE

CREATE TABLE ... LIKE を使用して、元のテーブルに定義されているカラム属性やインデックスなど、別のテーブルの定義に基づいて空のテーブルを作成します:
```
CREATE TABLE new_tbl LIKE orig_tbl;
```
詳細は、セクション13.1.20.3「CREATE TABLE ... LIKE ステートメント」を参照してください。
[AS] query_expression

別のテーブルからテーブルを作成するには、CREATE TABLE ステートメントの最後に SELECT ステートメントを追加します:
```
CREATE TABLE new_tbl AS SELECT * FROM orig_tbl;
```
詳細は、セクション13.1.20.4「CREATE TABLE ... SELECT ステートメント」を参照してください。
IGNORE | REPLACE

IGNORE および REPLACE オプションは、SELECT ステートメントを使用してテーブルをコピーするときに一意キー値を複製する行の処理方法を示します。

詳細は、セクション13.1.20.4「CREATE TABLE ... SELECT ステートメント」を参照してください。

カラムのデータ型および属性

テーブルあたり 4096 カラムという強い制限値がありますが、特定のテーブルでは、実際の最大数がこれより少なくなる可能性があります。実際の最大数は、セクション8.4.7「テーブルカラム数と行サイズの制限」で説明されている要因によって異なります。

data_type

data_type は、カラム定義のデータ型を表します。カラムのデータ型の指定に使用できる構文の詳細、および各型のプロパティの詳細は、第11章「データ型」を参照してください。
- 属性の中には、すべてのデータ型には適用されないものがあります。 AUTO_INCREMENT は、整数型と浮動小数点型にのみ適用されます。 MySQL 8.0.13 より前は、DEFAULT は BLOB, TEXT, GEOMETRY および JSON タイプには適用されません。
- 文字データ型 (CHAR、VARCHAR、TEXT 型、ENUM、SET およびシノニム) には、CHARACTER SET を含めてカラムの文字セットを指定できます。 CHARSET は CHARACTER SET のシノニムです。文字セットの照合順序は、他の属性とともに COLLATE 属性とともに指定できます。詳細は、第10章「文字セット、照合順序、Unicode」を参照してください。例:
```
CREATE TABLE t (c CHAR(20) CHARACTER SET utf8 COLLATE utf8_bin);
```
  MySQL 8.0 は、文字カラム定義内の長さの指定を文字数で解釈します。 BINARY と VARBINARY の長さはバイト単位です。
- CHAR、VARCHAR、BINARY、および VARBINARY カラムの場合は、col_name(length) 構文を使用してインデックスプリフィクス長を指定することにより、カラム値の先頭の部分のみを使用するインデックスを作成できます。 BLOB および TEXT カラムにもインデックスを設定できますが、プリフィクス長を指定する必要があります。プリフィクス長は、バイナリ以外の文字列型の場合は文字数で、バイナリ文字列型の場合はバイト単位で指定されます。つまり、インデックスエントリは、CHAR、VARCHAR、および TEXT カラムの場合は各カラム値の最初の length 文字、BINARY、VARBINARY、および BLOB カラムの場合は各カラム値の最初の length バイトで構成されます。このようにカラム値のプリフィクスのみにインデックスを設定すると、インデックスファイルをはるかに小さくできます。インデックス接頭辞の詳細は、セクション13.1.15「CREATE INDEX ステートメント」を参照してください。
  
  BLOB および TEXT カラム上のインデックス設定をサポートするのは、InnoDB および MyISAM ストレージエンジンだけです。例:
```
CREATE TABLE test (blob_col BLOB, INDEX(blob_col(10)));
```
  指定したインデックス接頭辞がカラムの最大データ型サイズを超える場合、CREATE TABLE は次のようにインデックスを処理します:
  - 一意でないインデックスの場合は、エラーが発生するか (厳密な SQL モードが有効な場合)、インデックスの長さが最大カラムデータ型サイズ内になるように縮小され、警告が生成されます (厳密な SQL モードが有効でない場合)。
  - 一意インデックスの場合、インデックスの長さを短くすると、指定した一意性要件を満たさない一意でないエントリの挿入が可能になるため、SQL モードに関係なくエラーが発生します。
- JSON カラムはインデックス付けできません。この制限を回避するには、生成されたカラムに JSON カラムからスカラー値を抽出するインデックスを作成します。詳細な例は、JSON カラムインデックスを提供するための生成されたカラムのインデックス付けを参照してください。
NOT NULL | NULL

NULL と NOT NULL のどちらも指定されていない場合、そのカラムは NULL が指定されたかのように処理されます。

MySQL 8.0 では、InnoDB、MyISAM および MEMORY ストレージエンジンのみが NULL 値を持つことができるカラムのインデックスをサポートしています。それ以外の場合は、インデックス付きカラムを NOT NULL として宣言する必要があります。そうしないと、エラー結果が発生します。
DEFAULT

カラムのデフォルト値を指定します。カラム定義に明示的な DEFAULT 値が含まれていない場合など、デフォルト値の処理の詳細は、セクション11.6「データ型デフォルト値」を参照してください。

NO_ZERO_DATE または NO_ZERO_IN_DATE SQL モードが有効になっているときに、日付の値のデフォルトがそのモードに従って正しくない場合、CREATE TABLE では厳密な SQL モードが有効になっていない場合は警告を、厳密モードが有効になっている場合はエラーを生成します。たとえば、NO_ZERO_IN_DATE が有効になっている場合は、c1 DATE DEFAULT '2010-00-00' によって警告が生成されます。
VISIBLE, INVISIBLE

カラムの可視性を指定します。どちらのキーワードも存在しない場合、デフォルトは VISIBLE です。テーブルには、少なくとも 1 つの表示可能なカラムが必要です。すべてのカラムを非表示にしようとすると、エラーが発生します。詳細は、セクション13.1.20.10「非表示カラム」を参照してください。

VISIBLE および INVISIBLE キーワードは、MySQL 8.0.23 の時点で使用できます。 MySQL 8.0.23 より前は、すべてのカラムが表示されます。
AUTO_INCREMENT

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

行を挿入したあとに AUTO_INCREMENT 値を取得するには、LAST_INSERT_ID() SQL 関数または mysql_insert_id() C API 関数を使用します。セクション12.16「情報関数」およびmysql_insert_id()を参照してください。

NO_AUTO_VALUE_ON_ZERO SQL モードが有効になっている場合は、新しいシーケンス値を生成することなく、0 を AUTO_INCREMENT カラム内に 0 として格納できます。セクション5.1.11「サーバー SQL モード」を参照してください。

テーブルごとに存在できる AUTO_INCREMENT カラムは 1 つだけです。このカラムはインデックス付きである必要があり、DEFAULT 値を割り当てることはできません。 AUTO_INCREMENT カラムは、正の値だけが含まれている場合にのみ正しく機能します。負の数を挿入すると、非常に大きな正の数を挿入したと見なされます。これは、数字が正から負に「ラップする」ときの精度の問題を回避すると同時に、0 を含む AUTO_INCREMENT カラムを誤って取得してしまわないようにするために行われます。

MyISAM テーブルの場合は、マルチカラムキー内の AUTO_INCREMENT セカンダリカラムを指定できます。セクション3.6.9「AUTO_INCREMENT の使用」を参照してください。

MySQL を一部の ODBC アプリケーションと互換性があるようにするために、次のクエリーを使用して、最後に挿入された行の AUTO_INCREMENT 値を見つけることができます。
```
SELECT * FROM tbl_name WHERE auto_col IS NULL
```
このメソッドでは、sql_auto_is_null 変数が 0 に設定されていない必要があります。セクション5.1.8「サーバーシステム変数」を参照してください。

InnoDB と AUTO_INCREMENT については、セクション15.6.1.6「InnoDB での AUTO_INCREMENT 処理」を参照してください。 AUTO_INCREMENT と MySQL レプリケーションについては、セクション17.5.1.1「レプリケーションと AUTO_INCREMENT」を参照してください。
COMMENT

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

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

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

NDB Cluster では、COLUMN_FORMAT=FIXED で定義されたカラムの可能な最大オフセットは 8188 バイトです。詳細および考えられる回避策については、セクション23.1.7.5「NDB Cluster 内のデータベースオブジェクトに関連付けられる制限」を参照してください。

COLUMN_FORMAT は現在、NDB 以外のストレージエンジンを使用しているテーブルのカラムには影響を与えません。 MySQL 8.0 は、COLUMN_FORMAT を暗黙的に無視します。
ENGINE_ATTRIBUTE および SECONDARY_ENGINE_ATTRIBUTE オプション (MySQL 8.0.21 の時点で使用可能) を使用して、プライマリおよびセカンダリストレージエンジンのカラム属性を指定します。オプションは、将来の使用のために予約されています。

許可される値は、有効な JSON ドキュメントまたは空の文字列 ('') を含む文字列リテラルです。無効な JSON が拒否されました。
```
CREATE TABLE t1 (c1 INT ENGINE_ATTRIBUTE='{"key":"value"}');
```
ENGINE_ATTRIBUTE および SECONDARY_ENGINE_ATTRIBUTE の値は、エラーなしで繰り返すことができます。この場合、最後に指定した値が使用されます。

ENGINE_ATTRIBUTE および SECONDARY_ENGINE_ATTRIBUTE の値は、サーバーによってチェックされず、テーブルストレージエンジンが変更されたときにもクリアされません。
STORAGE

NDB テーブルの場合、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 以外のストレージエンジンを使用しているテーブルには影響を与えません。 STORAGE キーワードは NDB Cluster で提供される mysqld の構築でのみサポートされます。ほかのバージョンの MySQL では認識されず、STORAGE キーワードを使用しようとすると構文エラーが発生します。
GENERATED ALWAYS

生成されたカラム式を指定するために使用します。 generated columns の詳細は、セクション13.1.20.8「CREATE TABLE および生成されるカラム」を参照してください。

Stored generated columns はインデックス付けできます。 InnoDB は、virtual generated columns でセカンダリインデックスをサポートしています。セクション13.1.20.9「セカンダリインデックスと生成されたカラム」を参照してください。

インデックス、外部キーおよび CHECK 制約

インデックス、外部キーおよび CHECK 制約の作成には、いくつかのキーワードが適用されます。次の説明に加えて、一般的な背景は、セクション13.1.15「CREATE INDEX ステートメント」、セクション13.1.20.5「FOREIGN KEY の制約」およびセクション13.1.20.6「CHECK 制約」を参照してください。

CONSTRAINT symbol

CONSTRAINT symbol 句を指定して制約に名前を付けることができます。句が指定されていない場合、または CONSTRAINT キーワードの後に symbol が含まれていない場合、MySQL では制約名が自動的に生成されますが、次に示す例外があります。 symbol 値 (使用する場合) は、制約タイプごとにスキーマ (データベース) ごとに一意である必要があります。 symbol が重複すると、エラーになります。セクション9.2.1「識別子の長さ制限」で生成される制約識別子の長さ制限に関する説明も参照してください。

注記

外部キー定義に CONSTRAINT symbol 句が指定されていない場合、または CONSTRAINT キーワードの後に symbol が含まれていない場合、MySQL は MySQL 8.0.15 までの外部キーインデックス名を使用し、その後に制約名を自動的に生成します。

SQL 標準では、すべてのタイプの制約 (主キー、一意インデックス、外部キー、チェック) が同じネームスペースに属することが指定されています。 MySQL では、各制約タイプにスキーマごとに独自のネームスペースがあります。したがって、各タイプの制約の名前はスキーマごとに一意である必要がありますが、異なるタイプの制約には同じ名前を付けることができます。
PRIMARY KEY

すべてのキーカラムを NOT NULL として定義する必要がある一意のインデックス。それらが NOT NULL として明示的に宣言されていない場合、MySQL は、それらを暗黙的に (かつ警告なしで) そのように宣言します。テーブルに存在できる PRIMARY KEY は 1 つだけです。 PRIMARY KEY の名前は、常に PRIMARY です。そのため、これをその他のどの種類のインデックスの名前としても使用できません。

PRIMARY KEY が存在しないときに、アプリケーションがテーブル内の PRIMARY KEY を要求した場合、MySQL は、NULL カラムのない最初の UNIQUE インデックスを PRIMARY KEY として返します。

InnoDB テーブルでは、セカンダリインデックスのためのストレージのオーバーヘッドを最小限に抑えるために、PRIMARY KEY を短い値に維持してください。各セカンダリインデックスエントリには、対応する行の主キーカラムのコピーが含まれています。 (セクション15.6.2.1「クラスタインデックスとセカンダリインデックス」を参照してください。)

作成されたテーブルでは、PRIMARY KEY が最初に配置され、そのあとにすべての UNIQUE インデックス、さらに一意でないインデックスが続きます。これは、MySQL オプティマイザが、使用するインデックスに優先順位を付けたり、重複した UNIQUE キーをよりすばやく検出したりするのに役立ちます。

PRIMARY KEY をマルチカラムインデックスにすることができます。ただし、カラム指定で PRIMARY KEY キー属性を使用してマルチカラムインデックスを作成することはできません。それを行なっても、その単一カラムがプライマリとしてマークされるだけです。別の PRIMARY KEY(key_part, ...) 句を使用する必要があります。

テーブルに整数型の単一カラムで構成される PRIMARY KEY または UNIQUE NOT NULL インデックスがある場合、一意インデックスで説明されているように、_rowid を使用して SELECT ステートメントのインデックス付きカラムを参照できます。

MySQL では、PRIMARY KEY の名前は PRIMARY です。その他のインデックスでは、名前を割り当てなかった場合、そのインデックスには最初のインデックス付きカラムと同じ名前が割り当てられ、それを一意にするためにオプションのサフィクス (_2、_3、...) が付けられます。テーブルのインデックス名は、SHOW INDEX FROM tbl_name を使用して確認できます。セクション13.7.7.22「SHOW INDEX ステートメント」を参照してください。
KEY | INDEX

KEY は通常、INDEX のシノニムです。キー属性 PRIMARY KEY もまた、カラム定義内で指定する場合は、単に KEY として指定できます。これは、ほかのデータベースシステムとの互換性のために実装されました。
UNIQUE

UNIQUE インデックスは、そのインデックス内のすべての値が異なっている必要があるという制約を作成します。既存の行に一致するキー値を持つ新しい行を追加しようとすると、エラーが発生します。すべてのエンジンについて、UNIQUE インデックスは、NULL を含むことができるカラムでの複数の NULL 値を許可します。 UNIQUE インデックスのカラムに接頭辞値を指定する場合、カラム値は接頭辞の長さ内で一意である必要があります。

テーブルに整数型の単一カラムで構成される PRIMARY KEY または UNIQUE NOT NULL インデックスがある場合、一意インデックスで説明されているように、_rowid を使用して SELECT ステートメントのインデックス付きカラムを参照できます。
FULLTEXT

FULLTEXT インデックスは、全文検索に使用される特別なタイプのインデックスです。 FULLTEXT インデックスをサポートするのは、InnoDB および MyISAM だけです。これらは、CHAR、VARCHAR、および TEXT カラムからのみ作成できます。インデックス設定は常に、カラム全体に対して実行されます。カラムプリフィクスのインデックス設定はサポートされていないため、プリフィクス長が指定されてもすべて無視されます。操作の詳細は、セクション12.10「全文検索関数」を参照してください。 WITH PARSER 句は、全文インデックス設定および検索操作に特殊な処理が必要な場合にパーサープラグインをインデックスに関連付けるために、index_option 値として指定できます。この句は、FULLTEXT インデックスに対してのみ有効です。 InnoDB および MyISAM は、フルテキストパーサープラグインをサポートしています。詳細は、Full-Text Parser Plugins および Writing Full-Text Parser Plugins を参照してください。
SPATIAL

空間データ型に SPATIAL インデックスを作成できます。空間型は InnoDB および MyISAM テーブルでのみサポートされており、インデックス付けされたカラムは NOT NULL として宣言する必要があります。セクション11.4「空間データ型」を参照してください。
FOREIGN KEY

MySQL は、関連データのテーブルにまたがる相互参照を可能にする外部キーと、この分散したデータの整合性を維持するために役立つ外部キー制約をサポートします。定義およびオプションの情報は、reference_definition および reference_option を参照してください。

InnoDB ストレージエンジンを使用するパーティション化されたテーブルは、外部キーをサポートしていません。詳細については、セクション24.6「パーティショニングの制約と制限」を参照してください。
CHECK

CHECK 句を使用すると、テーブルの行のデータ値について制約を作成できます。セクション13.1.20.6「CHECK 制約」を参照してください。
key_part
- key_part 仕様の末尾には、ASC または DESC を使用して、インデックス値を昇順または降順のどちらで格納するかを指定できます。順序指定子が指定されていない場合、デフォルトは昇順です。
- length 属性で定義される接頭辞の長さは、REDUNDANT または COMPACT の行形式を使用する InnoDB テーブルでは最大 767 バイトです。 DYNAMIC または COMPRESSED の行形式を使用する InnoDB テーブルでは、接頭辞の長さの制限は 3072 バイトです。 MyISAM テーブルの場合、接頭辞の長さの制限は 1000 バイトです。
  
  接頭辞 limits はバイト単位で測定されます。ただし、CREATE TABLE、ALTER TABLE および CREATE INDEX ステートメントのインデックス指定の接頭辞 lengths は、非バイナリ文字列型 (CHAR, VARCHAR, TEXT) の場合は文字数として解釈され、バイナリ文字列型 (BINARY, VARBINARY, BLOB) の場合はバイト数として解釈されます。マルチバイト文字セットを使用する非バイナリ文字列カラムに接頭辞の長さを指定する場合は、これを考慮してください。
- MySQL 8.0.17 以降、key_part 仕様の expr では、(CAST json_path AS type ARRAY) の形式を使用して JSON カラムに複数値インデックスを作成できます。複数値インデックスでは、複数値インデックスの作成、使用方法、制限および制限に関する詳細情報を提供します。
index_type

一部のストレージエンジンでは、インデックスの作成時にインデックスタイプを指定できます。 index_type 指定子の構文は、USING type_name です。

例:
```
CREATE TABLE lookup
  (id INT, INDEX USING BTREE (id))
  ENGINE = MEMORY;
```
USING の推奨される位置は、インデックスカラムリストのあとです。カラムリストの前に指定できますが、その位置でのオプションの使用のサポートは非推奨であるため、将来の MySQL リリースで削除される予定です。
index_option

index_option 値は、インデックスの追加オプションを指定します。
- KEY_BLOCK_SIZE
  
  MyISAM テーブルの場合、KEY_BLOCK_SIZE はオプションで、インデックスキーブロックに使用するサイズをバイト単位で指定します。この値はヒントとして扱われます。必要に応じて、異なるサイズが使用される可能性があります。個々のインデックス定義に指定された KEY_BLOCK_SIZE 値は、テーブルレベルの KEY_BLOCK_SIZE 値をオーバーライドします。
  
  テーブルレベルの KEY_BLOCK_SIZE 属性の詳細は、テーブルオプションを参照してください。
- WITH PARSER
  
  WITH PARSER オプションは、FULLTEXT インデックスでのみ使用できます。これは、全文インデックス設定および検索操作に特殊な処理が必要な場合に、パーサープラグインをインデックスに関連付けます。 InnoDB および MyISAM は、フルテキストパーサープラグインをサポートしています。フルテキストパーサープラグインが関連付けられた MyISAM テーブルがある場合は、ALTER TABLE を使用してテーブルを InnoDB に変換できます。
- COMMENT
  
  インデックス定義には、最大 1024 文字のオプションのコメントを含めることができます。
  
  index_option COMMENT 句を使用して、個々のインデックスに InnoDB MERGE_THRESHOLD 値を設定できます。セクション15.8.11「インデックスページのマージしきい値の構成」を参照してください。
- VISIBLE, INVISIBLE
  
  インデックスの可視性を指定します。インデックスはデフォルトで可視化されます。不可視インデックスはオプティマイザでは使用されません。インデックスの可視性の指定は、主キー以外のインデックス (明示的または暗黙的) に適用されます。詳細は、セクション8.3.12「不可視のインデックス」を参照してください。
- ENGINE_ATTRIBUTE および SECONDARY_ENGINE_ATTRIBUTE オプション (MySQL 8.0.21 の時点で使用可能) は、プライマリストレージエンジンおよびセカンダリストレージエンジンのインデックス属性を指定するために使用されます。オプションは、将来の使用のために予約されています。
許容される index_option 値の詳細は、セクション13.1.15「CREATE INDEX ステートメント」を参照してください。インデックスの詳細は、セクション8.3.1「MySQL のインデックスの使用の仕組み」を参照してください。
reference_definition

reference_definition 構文の詳細および例は、セクション13.1.20.5「FOREIGN KEY の制約」を参照してください。

InnoDB および NDB テーブルは、外部キー制約のチェックをサポートしています。参照されるテーブルのカラムには、常に明示的に名前を付ける必要があります。外部キーに対しては ON DELETE と ON UPDATE の両方のアクションがサポートされています。詳細および例については、セクション13.1.20.5「FOREIGN KEY の制約」を参照してください。

その他のストレージエンジンの場合、MySQL Server は、CREATE TABLE ステートメント内の FOREIGN KEY および REFERENCES 構文を解析して無視します。セクション1.7.2.3「FOREIGN KEY 制約の違い」を参照してください。

重要

ANSI/ISO SQL 標準に精通しているユーザーの場合は、参照整合性の制約定義で使用される MATCH 句を認識または適用するストレージエンジンは (InnoDB を含め) 存在しません。明示的な MATCH 句を使用しても効果はなく、ON DELETE 句および ON UPDATE 句も無視されます。これらの理由により、MATCH の指定は避けるようにしてください。

SQL 標準での MATCH 句は、複合 (マルチカラム) 外部キー内の NULL 値が、主キーとの比較時にどのように処理されるかを制御します。 InnoDB は基本的に、外部キーをすべてまたは部分的に NULL にすることが許可される、MATCH SIMPLE で定義されるセマンティクスを実装しています。その場合は、このような外部キーを含む (子テーブルの) 行の挿入が許可され、その行は参照される (親) テーブル内のどの行にも一致しません。トリガーを使用して、ほかのセマンティクスを実装できます。

さらに、MySQL ではパフォーマンスのために、参照されるカラムにインデックスを設定する必要があります。ただし、InnoDB では、参照カラムを UNIQUE または NOT NULL として宣言する必要はありません。一意でないキーまたは NULL 値を含むキーへの外部キー参照の処理は、UPDATE や DELETE CASCADE などの操作に対して適切に定義されていません。 UNIQUE (または PRIMARY) と NOT NULL の両方であるキーのみを参照する外部キーを使用することをお勧めします。

MySQL は、参照がカラム指定の一部として定義されている「「インライン REFERENCES 仕様」」 (SQL 標準で定義されているもの) を解析しますが、無視します。 MySQL は、個別の FOREIGN KEY 指定の一部として指定されている場合にのみ REFERENCES 句を受け入れます。
reference_option

RESTRICT, CASCADE, SET NULL, NO ACTION および SET DEFAULT オプションの詳細は、セクション13.1.20.5「FOREIGN KEY の制約」を参照してください。

テーブルオプション

テーブルオプションは、テーブルの動作を最適化するために使用します。ほとんどの場合は、それらのうちのどれも指定する必要はありません。特に示されていないかぎり、これらのオプションはすべてのストレージエンジンに適用されます。特定のストレージエンジンに適用されないオプションは、テーブル定義の一部として受け入れられ、記憶される可能性があります。それにより、あとで ALTER TABLE を使用して、別のストレージエンジンを使用するようにテーブルを変換した場合に、このようなオプションが適用されます。

ENGINE

次のテーブルに示すいずれかの名前を使用して、テーブルのストレージエンジンを指定します。エンジン名は、引用符で囲んでも囲まなくてもかまいません。引用符で囲まれた名前 'DEFAULT' は認識されますが、無視されます。

ストレージエンジン	説明
`InnoDB`	行ロックと外部キーを備えたトランザクションセーフテーブル。新しいテーブルのためのデフォルトのストレージエンジン。 MySQL は経験しているが、`InnoDB` がはじめてである場合は、第15章「InnoDB ストレージエンジン」、そのなかでも特にセクション15.1「InnoDB 入門」を参照してください。
`MyISAM`	主に読み取り専用または読み取りが大半のワークロードに使用される、バイナリの移植可能なストレージエンジン。セクション16.2「MyISAM ストレージエンジン」を参照してください。
`MEMORY`	このストレージエンジンのデータは、メモリー内にのみ格納されます。セクション16.3「MEMORY ストレージエンジン」を参照してください。
`CSV`	カンマ区切り値形式で行を格納するテーブル。セクション16.4「CSV ストレージエンジン」を参照してください。
`ARCHIVE`	アーカイブストレージエンジン。セクション16.5「ARCHIVE ストレージエンジン」を参照してください。
`EXAMPLE`	サンプルのエンジン。セクション16.9「EXAMPLE ストレージエンジン」を参照してください。
`FEDERATED`	リモートテーブルにアクセスするストレージエンジン。セクション16.8「FEDERATED ストレージエンジン」を参照してください。
`HEAP`	これは `MEMORY` のシノニムです。
`MERGE`	1 つのテーブルとして使用される `MyISAM` テーブルのコレクション。 `MRG_MyISAM` とも呼ばれます。セクション16.7「MERGE ストレージエンジン」を参照してください。
`NDB`	トランザクションと外部キーをサポートする、クラスタ化された、耐障害の、メモリーベースのテーブル。 `NDBCLUSTER` とも呼ばれます。第23章「MySQL NDB Cluster 8.0」を参照してください。

デフォルトでは、使用できないストレージエンジンが指定されている場合、ステートメントはエラーで失敗します。この動作をオーバーライドするには、サーバーの SQL モードから NO_ENGINE_SUBSTITUTION を削除します (セクション5.1.11「サーバー SQL モード」を参照)。これにより、MySQL では、指定されたエンジンをデフォルトのストレージエンジンに置き換えることができます。通常、このような場合、これは default_storage_engine システム変数のデフォルト値である InnoDB です。 NO_ENGINE_SUBSTITUTION が無効になっている場合、ストレージエンジンの指定が受け入れられないと警告が発生します。

AUTOEXTEND_SIZE

テーブルスペースが一杯になったときに InnoDB がテーブルスペースのサイズを拡張する量を定義します。 MySQL 8.0.23 で導入されました。設定は 4MB の倍数である必要があります。デフォルト設定は 0 で、暗黙的なデフォルト動作に従ってテーブルスペースが拡張されます。詳細は、セクション15.6.3.9「テーブルスペースの AUTOEXTEND_SIZE 構成」を参照してください。
AUTO_INCREMENT

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

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

テーブルの平均の行の長さの近似値。これを設定する必要があるのは、可変サイズの行を持つ大きなテーブルの場合だけです。

MyISAM テーブルを作成すると、MySQL は MAX_ROWS および AVG_ROW_LENGTH オプションの積を使用して、結果として得られるテーブルがどれくらいの大きさになるかを判定します。どちらのオプションも指定しない場合、MyISAM データおよびインデックスファイルの最大サイズは、デフォルトで 256T バイトになります。 (オペレーティングシステムでその大きさのファイルがサポートされていない場合、テーブルサイズはファイルサイズ制限によって制約されます。) インデックスをより小さく、かつ高速にするためにポインタサイズを小さく維持したいと考えており、実際に大きなファイルが必要でない場合は、myisam_data_pointer_size システム変数を設定することによってデフォルトのポインタサイズを小さくすることができます。 (セクション5.1.8「サーバーシステム変数」を参照してください。) すべてのテーブルをデフォルトの制限を超えて拡張できるようにしたいと考えており、テーブルが必要以上に少し遅く、かつ大きくなってもかまわない場合は、この変数を設定することによってデフォルトのポインタサイズを大きくすることができます。この値を 7 に設定すると、最大 65,536T バイトのテーブルサイズが許可されます。
[DEFAULT] CHARACTER SET

テーブルのデフォルトの文字セットを指定します。 CHARSET は CHARACTER SET のシノニムです。文字セット名が DEFAULT である場合は、データベース文字セットが使用されます。
CHECKSUM

MySQL ですべての行のライブチェックサム (つまり、テーブルが変更されると MySQL が自動的に更新するチェックサム) が保持されるようにする場合は、これを 1 に設定します。これにより、テーブルの更新が少し遅くなりますが、破損したテーブルを見つけることが容易になります。 CHECKSUM TABLE ステートメントは、このチェックサムをレポートします。 (MyISAM のみ。)
[DEFAULT] COLLATE

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

テーブルのコメントであり、長さは最大 2048 文字です。

table_option COMMENT 句を使用して、テーブルの InnoDB MERGE_THRESHOLD 値を設定できます。セクション15.8.11「インデックスページのマージしきい値の構成」を参照してください。

「NDB_TABLE の設定」オプション. NDB テーブルを作成する CREATE TABLE のまたは変更する ALTER TABLE ステートメントのテーブルコメントは、NDB_TABLE オプション NOLOGGING, READ_BACKUP, PARTITION_BALANCE、または FULLY_REPLICATED の 1 つから 4 つを指定するのに使用でき、カンマ区切り (必要ならば) の名前 - 値ペアのセットとして、引用符付きテキストで始まる文字列 NDB_TABLE= の直後に続きます。この構文を使用したステートメントの例を次に示します (強調されたテキスト):
```
CREATE TABLE t1 (
    c1 INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
    c2 VARCHAR(100),
    c3 VARCHAR(100) )
ENGINE=NDB
COMMENT="NDB_TABLE=READ_BACKUP=0,PARTITION_BALANCE=FOR_RP_BY_NODE";
```
引用符で囲まれた文字列内ではスペースを使用できません。文字列では大文字と小文字は区別されません。

コメントは、SHOW CREATE TABLE の出力の一部として表示されます。コメントのテキストは、MySQL Information Schema TABLES テーブルの TABLE_COMMENT カラムとしても使用できます。

このコメント構文は、NDB テーブルの ALTER TABLE ステートメントでもサポートされています。 ALTER TABLE で使用されるテーブルコメントは、テーブルにある可能性のある既存のコメントを置き換えることに注意してください。

テーブルコメントでの MERGE_THRESHOLD オプションの設定は、NDB テーブルではサポートされていません (無視されます)。

完全な構文情報および例は、セクション13.1.20.11「NDB_TABLE オプションの設定」を参照してください。
COMPRESSION

InnoDB テーブルのページレベル圧縮に使用される圧縮アルゴリズム。サポートされている値は、Zlib、LZ4 および None です。 COMPRESSION 属性は、透過的ページ圧縮機能とともに導入されました。ページ圧縮は、file-per-table テーブルスペースに存在する InnoDB テーブルでのみサポートされており、スパースファイルおよびホールパンチをサポートする Linux および Windows プラットフォームでのみ使用できます。詳細は、セクション15.9.2「InnoDB ページ圧縮」を参照してください。
CONNECTION

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

注記

古いバージョンの MySQL は、接続文字列に COMMENT オプションを使用していました。
DATA DIRECTORY、INDEX DIRECTORY

InnoDB の場合、DATA DIRECTORY='directory'句を使用すると、データディレクトリ外にテーブルを作成できます。 DATA DIRECTORY 句を使用するには、innodb_file_per_table 変数を有効にする必要があります。完全なディレクトリパスを指定する必要があります。 MySQL 8.0.21 では、指定されたディレクトリは InnoDB で認識されている必要があります。詳細は、セクション15.6.1.2「外部でのテーブルの作成」を参照してください。

MyISAM テーブルを作成する場合は、DATA DIRECTORY='directory' 句、INDEX DIRECTORY='directory' 句、またはその両方を使用できます。これらは、それぞれ MyISAM テーブルのデータファイルとインデックスファイルを配置する場所を指定します。 InnoDB テーブルとは異なり、DATA DIRECTORY または INDEX DIRECTORY オプションで MyISAM テーブルを作成する場合、MySQL はデータベース名に対応するサブディレクトリを作成しません。各ファイルは、指定されたディレクトリ内に作成されます。

DATA DIRECTORY または INDEX DIRECTORY テーブルオプションを使用するには、FILE 権限が必要です。

重要

テーブルレベルの DATA DIRECTORY および INDEX DIRECTORY オプションは、パーティション化されたテーブルでは無視されます。 (Bug #32091)

これらのオプションは、--skip-symbolic-links オプションを使用していない場合にのみ機能します。また、オペレーティングシステムにも、機能するスレッドに対して安全な realpath() 呼び出しが存在する必要があります。詳細は、セクション8.12.2.2「Unix 上の MyISAM へのシンボリックリンクの使用」を参照してください。

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

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

重要

DATA DIRECTORY または INDEX DIRECTORY では、MySQL データディレクトリを含むパス名を使用できません。これには、パーティション化されたテーブルや個々のテーブルパーティションが含まれます。 (Bug #32167 を参照してください。)
DELAY_KEY_WRITE

テーブルのキー更新をテーブルが閉じられるまで遅らせる場合は、これを 1 に設定します。セクション5.1.8「サーバーシステム変数」にある delay_key_write システム変数の説明を参照してください。 (MyISAM のみ。)
ENCRYPTION

ENCRYPTION 句は、InnoDB テーブルのページレベルのデータ暗号化を有効または無効にします。暗号化を有効にする前に、キーリングプラグインをインストールして構成する必要があります。 MySQL 8.0.16 より前では、ENCRYPTION 句は file-per-table テーブルスペースにテーブルを作成する場合にのみ指定できます。 MySQL 8.0.16 では、一般的なテーブルスペースにテーブルを作成するときに ENCRYPTION 句を指定することもできます。

MySQL 8.0.16 では、ENCRYPTION 句が指定されていない場合、テーブルはデフォルトのスキーマ暗号化を継承します。 table_encryption_privilege_check 変数が有効になっている場合、デフォルトのスキーマ暗号化とは異なる ENCRYPTION 句設定を使用してテーブルを作成するには、TABLE_ENCRYPTION_ADMIN 権限が必要です。一般的なテーブルスペースにテーブルを作成する場合、テーブルとテーブルスペースの暗号化は一致する必要があります。

MySQL 8.0.16 の時点では、暗号化をサポートしていないストレージエンジンを使用する場合、'N'または''以外の値で ENCRYPTION 句を指定することはできません。以前は、条項は受け入れられました。

詳細は、セクション15.13「InnoDB 保存データ暗号化」を参照してください。
ENGINE_ATTRIBUTE および SECONDARY_ENGINE_ATTRIBUTE オプション (MySQL 8.0.21 の時点で使用可能) を使用して、プライマリおよびセカンダリストレージエンジンのテーブル属性を指定します。オプションは、将来の使用のために予約されています。

許可される値は、有効な JSON ドキュメントまたは空の文字列 ('') を含む文字列リテラルです。無効な JSON が拒否されました。
```
CREATE TABLE t1 (c1 INT) ENGINE_ATTRIBUTE='{"key":"value"}';
```
ENGINE_ATTRIBUTE および SECONDARY_ENGINE_ATTRIBUTE の値は、エラーなしで繰り返すことができます。この場合、最後に指定した値が使用されます。

ENGINE_ATTRIBUTE および SECONDARY_ENGINE_ATTRIBUTE の値は、サーバーによってチェックされず、テーブルストレージエンジンが変更されたときにもクリアされません。
INSERT_METHOD

MERGE テーブルにデータを挿入する場合は、INSERT_METHOD を使用して、行を挿入するテーブルを指定する必要があります。 INSERT_METHOD は、MERGE テーブルにのみ役立つオプションです。最初または最後のテーブルに挿入するには FIRST または LAST の値を、挿入されないようにするには NO の値を使用します。セクション16.7「MERGE ストレージエンジン」を参照してください。
KEY_BLOCK_SIZE

MyISAM テーブルの場合、KEY_BLOCK_SIZE はオプションで、インデックスキーブロックに使用するサイズをバイト単位で指定します。この値はヒントとして扱われます。必要に応じて、異なるサイズが使用される可能性があります。個々のインデックス定義に指定された KEY_BLOCK_SIZE 値は、テーブルレベルの KEY_BLOCK_SIZE 値をオーバーライドします。

InnoDB テーブルの場合、KEY_BLOCK_SIZE は compressed InnoDB テーブルに使用する page サイズを KB 単位で指定します。 KEY_BLOCK_SIZE 値は、ヒントとして処理されます。InnoDB では、必要に応じて異なるサイズが使用される可能性があります。 KEY_BLOCK_SIZE は、innodb_page_size 値以下にのみできます。値 0 は、innodb_page_size 値の半分であるデフォルトの圧縮済みページサイズを表します。 innodb_page_size に応じて、可能な KEY_BLOCK_SIZE 値には 0、1、2、4、8 および 16 が含まれます。詳しくはセクション15.9.1「InnoDB テーブルの圧縮」をご覧ください。

InnoDB テーブルに KEY_BLOCK_SIZE を指定する場合、Oracle では innodb_strict_mode を有効にすることをお薦めします。 innodb_strict_mode が有効な場合、無効な KEY_BLOCK_SIZE 値を指定するとエラーが返されます。 innodb_strict_mode が無効な場合、無効な KEY_BLOCK_SIZE 値は警告になり、KEY_BLOCK_SIZE オプションは無視されます。

SHOW TABLE STATUS に対するレスポンスの Create_options カラムには、SHOW CREATE TABLE と同様に、テーブルで使用される実際の KEY_BLOCK_SIZE がレポートされます。

InnoDB では、テーブルレベルでの KEY_BLOCK_SIZE のみがサポートされます。

KEY_BLOCK_SIZE は、32KB および 64KB の innodb_page_size 値ではサポートされていません。 InnoDB テーブル圧縮では、これらのページサイズはサポートされていません。

InnoDB では、一時テーブルの作成時に KEY_BLOCK_SIZE オプションをサポートしていません。
MAX_ROWS

テーブル内に格納することを予定している行の最大数。これは強い制限値ではなく、どちらかと言うと、テーブルが少なくともこの行数を格納できる必要があるという、ストレージエンジンへのヒントです。

重要

NDB テーブルで MAX_ROWS を使用してテーブルパーティションの数を制御することは非推奨です。下位互換性のために新しいバージョンでも引き続きサポートされますが、将来のリリースでは削除される予定です。かわりに PARTITION_BALANCE を使用してください。「NDB_TABLE の設定」オプションを参照してください。

NDB ストレージエンジンは、この値を最大値として扱います。非常に大きな「NDB Cluster」テーブル (数百万行を含む) を作成する場合は、このオプションを使用して、MAX_ROWS = 2 * rows を設定することで、NDB がテーブルの主キーのハッシュの格納に使用するハッシュテーブルに十分な数の索引スロットを割り当てるようにする必要があります (rows は、テーブルに挿入する予定の行数です)。

MAX_ROWS の最大値は 4294967295 です。これを超える値は、この制限に切り捨てられます。
MIN_ROWS

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

MyISAM テーブルでのみ有効です。インデックスを小さくする場合は、このオプションを 1 に設定します。通常は、これによって更新は遅く、読み取りは高速になります。このオプションを 0 に設定すると、キーのすべてのパッキングが無効になります。これを DEFAULT に設定すると、長い CHAR、VARCHAR、BINARY、または VARBINARY カラムのみをパックするようストレージエンジンに指示します。

PACK_KEYS を使用しない場合、デフォルトでは文字列をパックしますが、数値はパックしません。 PACK_KEYS=1 を使用した場合は、数値もパックされます。

2 進数のキーをパックする場合、MySQL は次のプリフィクス圧縮を使用します。
- 前のキーの何バイトが次のキーと同じであるかを示すために、すべてのキーに 1 バイトが余分に必要になります。
- 行へのポインタは、圧縮率を向上させるために、キーの直後に高位バイトが先に来る順序で格納されます。
つまり、2 つの連続した行に等しいキーが多数存在する場合は、次の「同じ」キーはすべて、通常 (行へのポインタを含め) 2 バイトしか占有しません。これを、次のキーが storage_size_for_key + pointer_size (ここで、ポインタサイズは通常 4) を占有する通常のケースと比較してください。逆に言うと、プリフィクス圧縮から大きな利点が得られるのは、同じ数値が多数存在する場合だけです。すべてのキーが完全に異なっている場合は、そのキーが NULL 値を持つことができるキーでないかぎり、キーあたり 1 バイト多く使用されます。 (この場合、パックされたキーの長さは、キーが NULL であるかどうかをマークするために使用されるのと同じバイトに格納されます。)
PASSWORD

このオプションは使用されません。
ROW_FORMAT

行が格納される物理フォーマットを定義します。

strict mode を無効にしてテーブルを作成する場合、指定した行フォーマットがサポートされていないと、ストレージエンジンのデフォルトの行フォーマットが使用されます。テーブルの実際の行形式は、SHOW TABLE STATUS に応じて Row_format カラムにレポートされます。 Create_options カラムには、SHOW CREATE TABLE と同様に、CREATE TABLE ステートメントで指定された行形式が表示されます。

行形式の選択は、テーブルに使用されるストレージエンジンによって異なります。

InnoDB テーブルの場合:
- デフォルトの行フォーマットは、DYNAMIC のデフォルト設定を持つ innodb_default_row_format によって定義されます。デフォルトの行フォーマットは、ROW_FORMAT オプションが定義されていない場合、または ROW_FORMAT=DEFAULT が使用されている場合に使用されます。
  
  ROW_FORMAT オプションが定義されていない場合、または ROW_FORMAT=DEFAULT が使用されている場合は、テーブルを再構築する操作によって、テーブルの行形式も innodb_default_row_format で定義されているデフォルトに暗黙的に変更されます。詳細は、テーブルの行形式の定義を参照してください。
- データ型 (特に BLOB 型) の InnoDB 記憶域をより効率的にするには、DYNAMIC を使用します。 DYNAMIC の行形式に関連する要件については、DYNAMIC 行フォーマットを参照してください。
- InnoDB テーブルの圧縮を有効にするには、ROW_FORMAT=COMPRESSED を指定します。一時テーブルを作成する場合、ROW_FORMAT=COMPRESSED オプションはサポートされません。 COMPRESSED の行形式に関連する要件については、セクション15.9「InnoDB のテーブルおよびページの圧縮」を参照してください。
- 以前のバージョンの MySQL で使用されていた行形式は、REDUNDANT の行形式を指定することで引き続きリクエストできます。
- デフォルト以外の ROW_FORMAT 句を指定する場合は、innodb_strict_mode 構成オプションも有効にすることを考慮してください。
- ROW_FORMAT=FIXED はサポートされていません。 innodb_strict_mode が無効になっているときに ROW_FORMAT=FIXED が指定された場合、InnoDB は警告を発行し、ROW_FORMAT=DYNAMIC とみなします。 innodb_strict_mode が有効になっている間に ROW_FORMAT=FIXED が指定されている場合 (デフォルト)、InnoDB はエラーを返します。
- InnoDB 行フォーマットの詳細は、セクション15.10「InnoDB の行フォーマット」を参照してください。
MyISAM テーブルの場合は、このオプション値を、静的行フォーマットまたは可変長行フォーマットを示す FIXED または DYNAMIC に設定できます。myisampack は、この型を COMPRESSED に設定します。セクション16.2.3「MyISAM テーブルのストレージフォーマット」を参照してください。

NDB テーブルの場合、デフォルトの ROW_FORMAT は DYNAMIC です。
STATS_AUTO_RECALC

InnoDB テーブルの永続的統計を自動的に再計算するかどうかを指定します。値 DEFAULT を指定すると、テーブルの永続的統計設定は innodb_stats_auto_recalc 構成オプションによって決定されます。値 1 を指定すると、統計は、テーブル内のデータの 10% が変更されたときに再計算されます。値 0 は、このテーブルの自動再計算が行われないようにします。この設定の場合、テーブルへの大幅な変更を行なったあとに統計を再計算するには、ANALYZE TABLE ステートメントを発行します。永続的統計機能の詳細は、セクション15.8.10.1「永続的オプティマイザ統計のパラメータの構成」を参照してください。
STATS_PERSISTENT

InnoDB テーブルの永続的統計を有効にするかどうかを指定します。値 DEFAULT を指定すると、テーブルの永続的統計設定は innodb_stats_persistent 構成オプションによって決定されます。値 1 がテーブルの永続的統計を有効にするのに対して、値 0 はこの機能を無効にします。 CREATE TABLE または ALTER TABLE ステートメントを使用して永続的統計を有効にしたあと、代表的なデータのテーブルへのロード後に統計を計算するには、ANALYZE TABLE ステートメントを発行します。永続的統計機能の詳細は、セクション15.8.10.1「永続的オプティマイザ統計のパラメータの構成」を参照してください。
STATS_SAMPLE_PAGES

インデックス付きカラムのカーディナリティーやその他の統計 (ANALYZE TABLE によって計算される統計など) を推定するときにサンプリングするインデックスページの数。詳細は、セクション15.8.10.1「永続的オプティマイザ統計のパラメータの構成」を参照してください。
TABLESPACE

TABLESPACE 句を使用すると、既存の一般テーブルスペース、file-per-table テーブルスペースまたはシステムテーブルスペースにテーブルを作成できます。
```
CREATE TABLE tbl_name ... TABLESPACE [=] tablespace_name
```
TABLESPACE 句を使用する前に、指定する一般テーブルスペースが存在している必要があります。一般テーブルスペースの詳細は、セクション15.6.3.3「一般テーブルスペース」を参照してください。

tablespace_name は、大/小文字を区別する識別子です。引用符で囲むことも、引用符で囲まないこともできます。スラッシュ文字 (「/」) は使用できません。「innodb_」で始まる名前は、特別な用途のために予約されています。

システムテーブルスペースにテーブルを作成するには、テーブルスペース名として innodb_system を指定します。
```
CREATE TABLE tbl_name ... TABLESPACE [=] innodb_system
```
TABLESPACE [=] innodb_system を使用すると、innodb_file_per_table の設定に関係なく、圧縮されていない行形式のテーブルをシステムテーブルスペースに配置できます。たとえば、TABLESPACE [=] innodb_system を使用して、ROW_FORMAT=DYNAMIC を含むテーブルをシステムテーブルスペースに追加できます。

file-per-table テーブルスペースにテーブルを作成するには、テーブルスペース名として innodb_file_per_table を指定します。
```
CREATE TABLE tbl_name ... TABLESPACE [=] innodb_file_per_table
```
注記

innodb_file_per_table が有効な場合、InnoDB file-per-table テーブルスペースを作成するために TABLESPACE=innodb_file_per_table を指定する必要はありません。 InnoDB テーブルは、innodb_file_per_table が有効な場合、デフォルトで file-per-table テーブルスペースに作成されます。

DATA DIRECTORY 句は CREATE TABLE ... TABLESPACE=innodb_file_per_table では許可されますが、それ以外の場合は TABLESPACE 句との組合せでの使用はサポートされていません。 MySQL 8.0.21 では、DATA DIRECTORY 句で指定されたディレクトリは InnoDB で認識されている必要があります。詳細は、DATA DIRECTORY 句の使用を参照してください。

注記

CREATE TEMPORARY TABLE での TABLESPACE = innodb_file_per_table 句および TABLESPACE = innodb_temporary 句のサポートは、MySQL 8.0.13 で非推奨になりました。MySQL の将来のバージョンで削除される予定です。

STORAGE テーブルオプションは、NDB テーブルでのみ使用されます。 STORAGE は、使用される記憶域のタイプ (ディスクまたはメモリー) を決定し、DISK または MEMORY のいずれかになります。

TABLESPACE ... STORAGE DISK は、「NDB Cluster ディスクデータ」テーブルスペースにテーブルを割り当てます。テーブルスペースは、CREATE TABLESPACE を使用してすでに作成されている必要があります。詳細は、セクション23.5.10「NDB Cluster ディスクデータテーブル」を参照してください。

重要

STORAGE 句を、TABLESPACE 句のない CREATE TABLE ステートメントで使用することはできません。
UNION

同一の MyISAM テーブルのコレクションにアクセスするために使用します。これは、MERGE テーブルでのみ機能します。セクション16.7「MERGE ストレージエンジン」を参照してください。

MERGE テーブルにマップするテーブルに対する SELECT、UPDATE、および DELETE 権限が必要です。

注記

以前は、使用されるすべてのテーブルが MERGE テーブル自体と同じデータベース内に存在する必要がありました。この制限は適用されなくなりました。

テーブルのパーティション化

partition_options を使用すると、CREATE TABLE で作成されたテーブルのパーティション化を制御できます。

このセクションの最初にある partition_options の構文に示されているすべてのオプションが、すべてのパーティショニングタイプに使用できるわけではありません。各タイプに固有の情報については、次の個々のタイプのリストを参照してください。また、MySQL でのパーティション化の動作や使用に関するより詳細な情報、および MySQL のパーティション化に関連したテーブル作成やその他のステートメントの追加の例については、第24章「パーティション化」を参照してください。

パーティションに対しては変更、マージ、テーブルへの追加、およびテーブルからの削除が可能です。これらのタスクを実行するための MySQL ステートメントに関する基本情報については、セクション13.1.9「ALTER TABLE ステートメント」を参照してください。より詳細な説明および例については、セクション24.3「パーティション管理」を参照してください。

PARTITION BY

partition_options 句が使用される場合、この句は PARTITION BY で始まります。この句には、パーティションを決定するために使用される関数が含まれています。この関数は、1 から num までの範囲の整数値を返します。ここで、num はパーティションの数です。 (テーブルに含めることのできるユーザー定義パーティションの最大数は 1024 です。この最大数には、このセクションのあとの方で説明されているサブパーティションの数が含まれています。)

注記

PARTITION BY 句で使用される式 (expr) は、作成されているテーブルにはないどのカラムも参照できません。このような参照は明確に禁止されており、そのステートメントがエラーで失敗する原因になります。 (Bug #29444)
HASH(expr)

1 つ以上のカラムをハッシュして、行を配置および検索するためのキーを作成します。expr は、1 つ以上のテーブルのカラムを使用する式です。これは、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), col3 DATETIME)
    PARTITION BY HASH ( YEAR(col3) );
```
PARTITION BY HASH では、VALUES LESS THAN または VALUES IN のどちらの句も使用できません。

PARTITION BY HASH は、expr をパーティションの数で割った余り (つまり、法) を使用します。例および追加情報については、セクション24.2.4「HASH パーティショニング」を参照してください。

LINEAR キーワードには、いくぶん異なるアルゴリズムが必要になります。この場合、行が格納されるパーティションの数は、1 つ以上の論理的な AND 演算の結果として計算されます。線形ハッシュの説明および例については、セクション24.2.4.1「LINEAR HASH パーティショニング」を参照してください。
KEY(column_list)

これは HASH と似ていますが、偶数のデータ分散を保証するために、MySQL がハッシュ関数を提供する点が異なります。 column_list 引数は、単純に 1 つ以上のテーブルカラム (最大 16 個) のリストです。この例は、4 つのパーティションを持つ、キーによってパーティション化された単純なテーブルを示しています。
```
CREATE TABLE tk (col1 INT, col2 CHAR(5), col3 DATE)
    PARTITION BY KEY(col3)
    PARTITIONS 4;
```
キーによってパーティション化されたテーブルの場合は、LINEAR キーワードを使用して線形パーティション化を採用できます。これには、HASH によってパーティション化されたテーブルの場合と同じ効果があります。つまり、パーティション番号は法ではなく、& 演算子を使用して見つけられます (詳細は、セクション24.2.4.1「LINEAR HASH パーティショニング」およびセクション24.2.5「KEY パーティショニング」を参照してください)。この例では、キーによる線形パーティション化を使用して 5 つのパーティション間でデータを分散させます。
```
CREATE TABLE tk (col1 INT, col2 CHAR(5), col3 DATE)
    PARTITION BY LINEAR KEY(col3)
    PARTITIONS 5;
```
ALGORITHM={1 | 2} オプションは、[SUB]PARTITION BY [LINEAR] KEY でサポートされます。 ALGORITHM=1 を指定すると、サーバーは MySQL 5.1 と同じキーハッシュ関数を使用します。ALGORITHM=2 は、サーバーが、MySQL 5.5 以降で実装され、KEY によってパーティション化された新しいテーブルに対してデフォルトで使用されるキーハッシュ関数を採用することを示します。 (MySQL 5.5 以降で採用されたキーハッシュ関数によって作成されたパーティション化されたテーブルを MySQL 5.1 サーバーで使用することはできません。) このオプションを指定しない場合は、ALGORITHM=2 を使用するのと同じ効果があります。このオプションは、主に [LINEAR] KEY によってパーティション化されたテーブルを MySQL 5.1 以降の MySQL バージョン間でアップグレードまたはダウングレードするときに使用するか、または MySQL 5.5 以降のサーバー上で、MySQL 5.1 サーバー上で使用できる KEY または LINEAR KEY によってパーティション化されたテーブルを作成することを目的にしています。詳細は、セクション13.1.9.1「ALTER TABLE パーティション操作」を参照してください。

MySQL 5.7 以降の mysqldump では、次のようにバージョニングされたコメントにこのオプションが含まれています:
```
CREATE TABLE t1 (a INT)
/*!50100 PARTITION BY KEY */ /*!50611 ALGORITHM = 1 */ /*!50100 ()
      PARTITIONS 3 */
```
これにより、MySQL 5.6.10 以前のサーバーはこのオプションを無視するようになります。これらのバージョンでは、通常であれば構文エラーが発生します。 KEY によってパーティション化またはサブパーティション化されたテーブルをバージョン 5.6.11 より前の MySQL 5.6 サーバーに使用する MySQL 5.7 サーバーで作成されたダンプをロードする場合は、先に進む前に Changes in MySQL 5.6 に問い合せてください。 (見つかった情報は、MySQL 5.7(事実上 5.6.11 または later-server) から作成された KEY パーティションテーブルまたはサブパーティションテーブルを含むダンプを MySQL 5.5.30 以前のサーバーにロードする場合にも適用されます。)

また、MySQL 5.6.11 以降では、ALGORITHM=1 が mysqldump と同じ方法で、バージョン管理されたコメントを使用して SHOW CREATE TABLE の出力に必要に応じて表示されます。 ALGORITHM=2 は、元のテーブルを作成するときにこのオプションが指定された場合でも、SHOW CREATE TABLE の出力から常に省略されます。

PARTITION BY KEY では、VALUES LESS THAN または VALUES IN のどちらの句も使用できません。

RANGE(expr)

この場合、expr では、一連の VALUES LESS THAN 演算子を使用して値の範囲が表示されます。範囲のパーティション化を使用する場合は、VALUES LESS THAN を使用して、少なくとも 1 つのパーティションを定義する必要があります。範囲のパーティション化では VALUES IN を使用できません。

注記

RANGE によってパーティション化されたテーブルでは、VALUES LESS THAN を整数リテラル値、または 1 つの整数値に評価される式のどちらかとともに使用する必要があります。 MySQL 8.0 では、このセクションのあとの方で説明されている、PARTITION BY RANGE COLUMNS を使用して定義されたテーブルでこの制限を克服できます。

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

パーティション番号:	年の範囲:
0	1990 以前
1	1991 から 1994 まで
2	1995 から 1998 まで
3	1999 から 2002 まで
4	2003 から 2005 まで
5	2006 以降

このようなパーティション化スキームを実装するテーブルは、次に示す 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 は、それ以外で指定されている最大値より大きい「残りの」値を指定するように機能します。

VALUES LESS THAN 句は、switch ... case ブロックの case 部分と同様の方法で順次機能します (C、Java、PHP などの多くのプログラミング言語で使用されています)。つまり、この句は、連続した各 VALUES LESS THAN で指定されている上限が前の句の上限より大きく、かつ MAXVALUE を参照している句がリスト内のすべての句の最後に来るような方法で配置されている必要があります。

RANGE COLUMNS(column_list)

RANGE のこのバリアントにより、複数のカラムで範囲条件を使用する (つまり、WHERE a = 1 AND b < 10 や WHERE a = 1 AND b = 10 AND c < 10 などの条件を持つ) クエリーのパーティションプルーニングが容易になります。これにより、COLUMNS 句内のカラムのリストと、各 PARTITION ... VALUES LESS THAN (value_list) パーティション定義句内のカラム値のセットを使用して、複数のカラム内の値の範囲を指定できるようになります。 (もっとも単純なケースでは、このセットは単一カラムで構成されます。) column_list および value_list で参照できるカラムの最大数は 16 です。

COLUMNS 句で使用される column_list には、カラムの名前のみを含めることができます。リスト内の各カラムは MySQL のデータ型のうち、整数型、文字列型、および時間または日付カラム型のいずれかである必要があります。 BLOB、TEXT、SET、ENUM、BIT、または空間データ型を使用したカラムは許可されていません。浮動小数点数型を使用するカラムも許可されていません。また、COLUMNS 句では、関数や演算式も使用できません。

パーティション定義で使用される VALUES LESS THAN 句は、COLUMNS() 句に現れるカラムごとにリテラル値を指定する必要があります。つまり、各 VALUES LESS THAN 句で使用される値のリストには、COLUMNS 句にリストされているカラムの数と同じ数の値が含まれている必要があります。 VALUES LESS THAN 句で COLUMNS 句に存在する数より多いか、または少ない値を使用しようとすると、このステートメントは次のエラーで失敗します。Inconsistency in usage of column lists for partitioning.... VALUES LESS THAN に現れるどの値にも NULL は使用できません。この例に示すように、最初のカラム以外の特定のカラムで MAXVALUE を複数回使用できます。
```
CREATE TABLE rc (
    a INT NOT NULL,
    b INT NOT NULL
)
PARTITION BY RANGE COLUMNS(a,b) (
    PARTITION p0 VALUES LESS THAN (10,5),
    PARTITION p1 VALUES LESS THAN (20,10),
    PARTITION p2 VALUES LESS THAN (50,MAXVALUE),
    PARTITION p3 VALUES LESS THAN (65,MAXVALUE),
    PARTITION p4 VALUES LESS THAN (MAXVALUE,MAXVALUE)
);
```
VALUES LESS THAN 値リストで使用されている各値が、対応するカラムの型に正確に一致している必要があります。変換は行われません。たとえば、整数型を使用するカラムに一致する値として文字列 '1' を使用したり (代わりに、数値 1 を使用する必要があります)、文字列型を使用するカラムに一致する値として数値 1 を使用したりすることはできません (このような場合は、引用符で囲まれた文字列 '1' を使用する必要があります)。

詳細は、セクション24.2.1「RANGE パーティショニング」およびセクション24.4「パーティションプルーニング」を参照してください。
LIST(expr)

これは、州や国コードなど、使用可能な値の制限されたセットを持つテーブルのカラムに基づいてパーティションを割り当てる場合に役立ちます。このような場合は、特定の州または国に関連するすべての行を単一パーティションに割り当てたり、特定の州または国のセットのためにパーティションを予約したりできます。これは RANGE に似ていますが、各パーティションに許可される値を指定するために VALUES IN しか使用できない点が異なります。

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 つのパーティションを定義する必要があります。 PARTITION BY LIST では VALUES LESS THAN を使用できません。

注記

LIST によってパーティション化されたテーブルでは、VALUES IN で使用される値リストを整数値のみで構成する必要があります。 MySQL 8.0 では、このセクションのあとの方で説明されている、LIST COLUMNS によるパーティション化を使用してこの制限を克服できます。
LIST COLUMNS(column_list)

LIST のこのバリアントにより、複数のカラムで比較条件を使用する (つまり、WHERE a = 5 AND b = 5 や WHERE a = 1 AND b = 10 AND c = 5 などの条件を持つ) クエリーのパーティションプルーニングが容易になります。これにより、COLUMNS 句内のカラムのリストと、各 PARTITION ... VALUES IN (value_list) パーティション定義句内のカラム値のセットを使用して、複数のカラム内の値を指定できるようになります。

LIST COLUMNS(column_list) で使用されるカラムリストと VALUES IN(value_list) で使用される値リストに関連したデータ型を管理するルールは、VALUES IN 句では MAXVALUE が許可されず、NULL を使用できる点を除き、それぞれ RANGE COLUMNS(column_list) で使用されるカラムリストと VALUES LESS THAN(value_list) で使用される値リストの場合のルールと同じです。

PARTITION BY LIST COLUMNS で VALUES IN に使用される値のリストには、PARTITION BY LIST で使用された場合と比較して重要な違いが 1 つあります。 PARTITION BY LIST COLUMNS で使用された場合、VALUES IN 句内の各要素は、カラム値のセットである必要があります。各セット内の値の数は COLUMNS 句で使用されているカラム数と同じである必要があり、これらの値のデータ型はそれらのカラムのデータ型に一致している (しかも、同じ順序で現れる) 必要があります。もっとも単純なケースでは、このセットは単一カラムで構成されます。 column_list および value_list を構成する各要素で使用できるカラムの最大数は 16 です。

次の CREATE TABLE ステートメントで定義されるテーブルは、LIST COLUMNS パーティション化を使用したテーブルの例を示しています。
```
CREATE TABLE lc (
    a INT NULL,
    b INT NULL
)
PARTITION BY LIST COLUMNS(a,b) (
    PARTITION p0 VALUES IN( (0,0), (NULL,NULL) ),
    PARTITION p1 VALUES IN( (0,1), (0,2), (0,3), (1,1), (1,2) ),
    PARTITION p2 VALUES IN( (1,0), (2,0), (2,1), (3,0), (3,1) ),
    PARTITION p3 VALUES IN( (1,3), (2,2), (2,3), (3,2), (3,3) )
);
```
PARTITIONS num

オプションで、PARTITIONS num 句を使用してパーティションの数を指定できます。ここで、num はパーティションの数です。この句とほかのいずれかの PARTITION 句の両方が使用されている場合、num は、PARTITION 句を使用して宣言されているすべてのパーティションの総数と同じである必要があります。

注記

RANGE または LIST によってパーティション化されたテーブルの作成で PARTITIONS 句を使用するかどうかにかかわらず、テーブル定義には引き続き、少なくとも 1 つの PARTITION VALUES 句を含める必要があります (下を参照してください)。
SUBPARTITION BY

オプションで、パーティションを複数のサブパーティションに分割できます。これは、オプションの SUBPARTITION BY 句を使用して示すことができます。サブパーティション化は、HASH または KEY によって実行できます。これらのどちらも LINEAR にすることができます。これらは、同等のパーティショニングタイプについて前に説明したのと同じように機能します。 (LIST または RANGE によってサブパーティション化することはできません。)

サブパーティションの数は、SUBPARTITIONS キーワードと、そのあとの整数値を使用して示すことができます。
PARTITIONS または SUBPARTITIONS 句で使用されている値の厳密なチェックが適用され、この値は次のルールに従っている必要があります。
- この値は 0 以外の正の整数である必要があります。
- 先頭の 0 は許可されません。
- この値は整数リテラルである必要があり、式にすることはできません。たとえば、0.2E+01 が 2 に評価されたとしても、PARTITIONS 0.2E+01 は許可されません。 (Bug #15890)
partition_definition

各パーティションは、partition_definition 句を使用して個別に定義できます。この句を構成する個別の部分は次のとおりです。
- PARTITION partition_name
  
  パーティションの論理名を指定します。
- VALUES
  
  レンジパーティション化では、各パーティションに VALUES LESS THAN 句が含まれている必要があります。リストパーティション化では、パーティションごとに VALUES IN 句を指定する必要があります。これは、このパーティションにどの行を格納するかを決定するために使用されます。構文の例については、第24章「パーティション化」にあるパーティショニングタイプの説明を参照してください。
- [STORAGE] ENGINE
  
  MySQL は、PARTITION と SUBPARTITION の両方に対して[STORAGE] ENGINE オプションを受け入れます。現在、このオプションを使用できる唯一の方法は、すべてのパーティションまたはすべてのサブパーティションを同じストレージエンジンに設定し、同じテーブル内のパーティションまたはサブパーティションに異なるストレージエンジンを設定しようとすると、「ERROR 1469 (HY000): パーティション内のハンドラの混在は、このバージョンの MySQL では許可されていません」エラーが発生することです。
- COMMENT
  
  オプションの COMMENT 句を使用すると、このパーティションを説明する文字列を指定できます。例:
```
COMMENT = 'Data for the years previous to 1999'
```
  パーティションコメントの最大長は 1024 文字です。
- DATA DIRECTORY および INDEX DIRECTORY
  
  DATA DIRECTORY と INDEX DIRECTORY は、それぞれ、このパーティションのデータとインデックスが格納されるディレクトリを示すために使用できます。 data_dir と index_dir はどちらも、絶対システムパス名である必要があります。
  
  MySQL 8.0.21 では、DATA DIRECTORY 句で指定されたディレクトリは InnoDB で認識されている必要があります。詳細は、DATA DIRECTORY 句の使用を参照してください。
  
  DATA DIRECTORY または INDEX DIRECTORY パーティションオプションを使用するには、FILE 権限が必要です。
  
  例:
```
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 p2002 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 つのデータディレクトリと 1 つのインデックスディレクトリを指定できます。指定されないままになっている場合、データとインデックスは、デフォルトではそのテーブルのデータベースディレクトリ内に格納されます。
  
  DATA DIRECTORY および INDEX DIRECTORY オプションは、NO_DIR_IN_CREATE が有効になっている場合、パーティション化されたテーブルの作成では無視されます。
- MAX_ROWS および MIN_ROWS
  
  パーティションに格納する行の最大数と最小数をそれぞれ指定するために使用できます。 max_number_of_rows と min_number_of_rows の値は正の整数である必要があります。同じ名前を持つテーブルレベルのオプションと同様に、これらはサーバーへの「提案」としてのみ機能し、強い制限値ではありません。
- TABLESPACE
  
  TABLESPACE `innodb_file_per_table`を指定して、パーティションの InnoDB file-per-table テーブルスペースを指定するために使用できます。すべてのパーティションは同じストレージエンジンに属している必要があります。
  
  InnoDB テーブルパーティションの共有 InnoDB テーブルスペースへの配置はサポートされていません。共有テーブルスペースには、InnoDB システムテーブルスペースおよび一般テーブルスペースが含まれます。
subpartition_definition

オプションで、パーティション定義に 1 つ以上の subpartition_definition 句を含めることができます。これらの各句は、少なくとも SUBPARTITION name で構成されます。ここで、name はそのサブパーティションの識別子です。 PARTITION キーワードが SUBPARTITION に置き換えられる点を除き、サブパーティション定義の構文はパーティション定義の構文と同じです。

サブパーティション化は HASH または KEY によって実行する必要があり、RANGE または LIST パーティションに対してのみ実行できます。セクション24.2.6「サブパーティショニング」を参照してください。

生成されたカラムによるパーティション化

生成されたカラムによるパーティション化が許可されます。例:

CREATE TABLE t1 (
  s1 INT,
  s2 INT AS (EXP(s1)) STORED
)
PARTITION BY LIST (s2) (
  PARTITION p1 VALUES IN (1)
);

パーティション化では、生成されたカラムは通常のカラムとして認識されます。これにより、パーティション化が許可されていない関数の制限の回避策が有効になります (セクション24.6.3「関数に関連するパーティショニング制限」を参照)。前述の例は、この方法を示しています: EXP() は PARTITION BY 句で直接使用できませんが、EXP() を使用して定義された生成されたカラムは許可されます。

PREV HOME UP NEXT