このトピックでは、CREATE TABLE ステートメントを使用して AnalyticDB for MySQL でパーティションテーブルとレプリケートテーブルを作成する方法、およびテーブルの分散キー、パーティションキー、インデックス、パーティションライフサイクル、ホットデータとコールドデータの階層型ストレージポリシーを指定する方法について説明します。
次の図は、テーブルを作成する前に理解しておく必要がある概念（シャード、パーティション、クラスタ化インデックスなど）を示しています。
構文
CREATE TABLE [IF NOT EXISTS] table_name
({column_name column_type [column_attributes] [ column_constraints ] [COMMENT 'column_comment']
| table_constraints}
[, ... ])
[table_attribute]
[partition_options]
[index_all]
[storage_policy]
[block_size]
[engine]
[table_properties]
[AS query_expr]
[COMMENT 'table_comment']
column_attributes:
[DEFAULT {constant | CURRENT_TIMESTAMP}]
[AUTO_INCREMENT]
column_constraints:
[{NOT NULL|NULL} ]
[PRIMARY KEY]
table_constraints:
[{INDEX|KEY} [index_name] (column_name|column_name->'$.json_path'|column_name->'$[*]')][,...]
[FULLTEXT [INDEX|KEY] [index_name] (column_name) [index_option]] [,...]
[PRIMARY KEY [index_name] (column_name,...)]
[CLUSTERED KEY [index_name] (column_name[ASC|DESC],...) ]
[[CONSTRAINT [symbol]] FOREIGN KEY (fk_column_name) REFERENCES pk_table_name (pk_column_name)][,...]
[ANN INDEX [index_name] (column_name,...) [index_option]] [,...]
table_attribute:
DISTRIBUTED BY HASH(column_name,...) | DISTRIBUTED BY BROADCAST
partition_options:
PARTITION BY
{VALUE(column_name) | VALUE(DATE_FORMAT(column_name, 'format')) | VALUE(FROM_UNIXTIME(column_name, 'format'))}
LIFECYCLE N
index_all:
INDEX_ALL= 'Y|N'
storage_policy:
STORAGE_POLICY= {'HOT'|'COLD'|'MIXED' {hot_partition_count=N}}
block_size:
BLOCK_SIZE= VALUE
engine:
ENGINE= 'XUANWU|XUANWU_V2'デフォルトでは、AnalyticDB for MySQL の内部テーブルは zstd 圧縮アルゴリズムを使用します。
パラメーター
table_name、column_name、column_type、および COMMENT
table_constraints (インデックス)
AnalyticDB for MySQL は、INDEX、PRIMARY KEY、CLUSTERED KEY、FOREIGN KEY、FULLTEXT INDEX、ANN INDEX など、さまざまなインデックスをサポートしています。テーブルには、1 つ以上のタイプのインデックスを含めることができます。
INDEX | KEY
標準インデックスを指定します。INDEX と KEY は同じ意味で使用できます。
XUANWU_V2 テーブルの場合、AnalyticDB for MySQL は、デフォルトではテーブルのすべての列にインデックスを作成しません。テーブルにプライマリキーが指定されている場合、AnalyticDB for MySQL は、デフォルトではプライマリキーにのみ標準インデックスを作成します。
XUANWU テーブルの場合、デフォルトではテーブルのすべての列にインデックスが作成されます。ただし、XUANWU テーブルを作成するときに特定の列にインデックスを作成する場合（
INDEX (id)を使用して id 列にインデックスを作成する場合など）、AnalyticDB for MySQL は、テーブルの他の列にインデックスを自動的に作成しません。
注: INDEX (column1,column2) を使用して複数の列に複合インデックスを作成することはできません。
PRIMARY KEY
プライマリキーインデックスを指定します。
概要
各テーブルには、プライマリキーを 1 つだけ設定できます。
プライマリキーは、
PRIMARY KEY (id)などの単一の列、またはPRIMARY KEY (id,name)などの複数の列で構成できます。複合プライマリキーには、分散キーとパーティションキーを含める必要があります。分散キーとパーティションキーは、複合プライマリキーの前方に配置することをお勧めします。
使用上の注意
プライマリキーのないテーブルでは、DELETE 操作または UPDATE 操作を実行できません。
プライマリキーを指定しない場合、次のルールが適用されます。
分散キーを指定しない場合、AnalyticDB for MySQL は、テーブルに 列を自動的に追加し、その列をプライマリキーと分散キー
__adb_auto_id__プライマリキーと分散キーとして使用します。分散キーが指定されている場合、AnalyticDB for MySQL プライマリキーを自動的に追加しません。
テーブルの作成後、プライマリキー列を追加、削除、または変更することはできません。
高いパフォーマンスを確保するために、1 つまたは少数の数値列をプライマリキーとして選択することをお勧めします。
テーブルに過剰なプライマリキー列がある場合、次の問題が発生する可能性があります。
CPU と I/O リソースの消費量の増加。これは、AnalyticDB for MySQL がデータの書き込み時に重複するプライマリキー値が存在するかどうかを確認するためです。
プライマリキーインデックスのディスク使用量の増加。プライマリキーインデックスのディスク使用量を表示するには、スペースの分析 機能を使用します。
BUILD ジョブのパーティション再構築速度の低下。
クラスタードキー
クラスタードインデックスを指定します。クラスタードインデックスはパーティションレベルで構成されます。これは、データが格納される物理的な順序を決定します。パーティション内のデータは、クラスタードインデックスの値に基づいてソートされ、順番に格納されます。デフォルトでは、データは昇順にソートおよび格納されます。クラスタードインデックスのキー値が同じか類似しているデータレコードは、同じか隣接したデータブロックに格納されます。範囲クエリまたは等価フィルタリングでは、クラスタードインデックスを使用すると、ディスク I/O を削減し、データの読み取りを高速化できます。これは、クエリ条件がクラスタードインデックス列と同じ場合、ストレージエンジンが連続したデータブロックを読み取ることができるためです。
適用可能なシナリオ
クラスタードインデックスは、範囲クエリと等価フィルタリングでうまく機能します。範囲クエリまたは等価フィルタリングの条件で頻繁に使用される列は、理想的なクラスタードインデックス列です。
クエリ条件がクラスタードインデックス列と一致するか部分的に一致する場合、読み取り効率が大幅に向上します。たとえば、SaaS（Software-as-a-Service）アプリケーションでユーザー ID をクラスタードインデックスとして使用できます。これにより、特定のユーザー ID のレコードが同じか連続したデータブロックに格納され、データクエリのパフォーマンスが向上します。
使用上の注意
各テーブルには、クラスタードインデックスを 1 つだけ設定できます。
クラスタードインデックスは、
CLUSTERED KEY index(id)などの単一の列、またはCLUSTERED KEY index(id,name)などの複数の列に作成できます。クラスタードインデックスに 2 つの列が関係する場合、データは最初に最初のクラスタードインデックス列の値に基づいてソートされます。最初のクラスタードインデックス列の値が同じ場合、データは 2 番目のクラスタードインデックス列の値に基づいてソートされます。したがって、CLUSTERED KEY index(id,name)とCLUSTERED KEY index(name,id)は異なるクラスタードインデックスです。デフォルトでは、クラスタードインデックスは昇順にソートされ、昇順クエリに適しています。クエリが降順の場合、テーブルを作成するときにクラスタードインデックスの順序を降順に設定します（例：
CLUSTERED KEY index(id) DESC）。既存のテーブルからデータをクエリする場合、既存のクラスタードインデックスを削除し、降順のクラスタードインデックスを作成できます。ソートパフォーマンスの低下を防ぐため、クラスタードインデックスで値が長い列（10 KB を超える文字列など）を使用しないことをお勧めします。
フルテキストインデックス | フルテキストキー
フルテキストインデックスを指定します。
外部キー
外部キーインデックスを指定します。外部キーインデックスは、不要な結合を排除するために使用されます。
ANN インデックス
ベクターインデックスを指定します。
注記：XUANWU_V2 テーブルのベクターインデックスは作成できません。
JSON インデックス
JSON インデックスまたは JSON 配列インデックスを指定します。
table_attribute (分散キー)
テーブルが標準テーブルかレプリケートテーブルかを決定します。
DISTRIBUTED BY HASH: テーブルを標準テーブルとして指定します。標準テーブルは、分散システムのクエリ機能を最大限に活用して、クエリ効率を向上させることができます。各標準テーブルには、最大数百億件のデータレコードを格納できます。
DISTRIBUTED BY BROADCAST: テーブルをレプリケートテーブルとして指定します。レプリケートテーブルは、テーブルが属する AnalyticDB for MySQL クラスタの各シャードにデータレプリカを格納します。各レプリケートテーブルには最大 20,000 行を格納することをお勧めします。
DISTRIBUTED BY HASH (column_name,...)
テーブルの分散キーを指定します。分散キーを持つテーブルは、パーティションテーブル (標準テーブル) です。AnalyticDB for MySQL は、分散キーのハッシュ値を計算し、ハッシュ値に基づいてテーブルをシャードに分割します。シャーディングは、スケーラビリティとクエリパフォーマンスを向上させます。
概要
各テーブルには、分散キーを 1 つだけ指定できます。
各分散キーには、1 つ以上の列を含めることができます。
分散キー列は、プライマリキー列に含まれている必要があります。たとえば、分散キーが customer_id 列の場合、プライマリキーには customer_id 列が含まれている必要があります。
使用上の注意
テーブルの作成時に分散キーを指定しない場合は、次のルールが適用されます。
テーブルにプライマリキーがある場合、AnalyticDB for MySQL はプライマリキーを分散キーとして使用します。
テーブルにプライマリキーがない場合、AnalyticDB for MySQL はテーブルに 列を自動的に追加し、その列をプライマリキーと分散キー
__adb_auto_id__プライマリキーと分散キーとして使用します。
テーブルが作成された後、分散キー列を追加、削除、または変更することはできません。分散キーを変更するには、必要な分散キーを持つテーブルを作成し、データを新しいテーブルに移行する必要があります。
推奨事項
列の数を少なく選択すると、さまざまな複雑なクエリに対して分散キーがより適したものになります。
値が均等に分散されている列を分散キーとして選択します。たとえば、トランザクション ID、デバイス ID、ユーザー ID、または自動増分列などです。ただし、これらの列は、クエリ条件が少数の列値に限定されている場合は、理想的な分散キーではありません。たとえば、列 A の値が均等に分散されているが、クエリ条件が常に A=3 の場合、列 A を分散キーとして設定すると、データホットスポットが発生します。
テーブルを結合するために使用できる列を分散キーとして選択します。こうすることで、結合された 2 つのテーブルで同じ分散キー値を持つデータが同じシャードに分散されます。結合操作は、シャード間でデータを送信する必要なく、同じシャードで実行されます。これにより、データの再分散が最小限に抑えられ、クエリのパフォーマンスが向上します。たとえば、ユースケースで顧客の注文履歴をクエリする場合、
customer_id列を分散キーとして指定できます。日付、時刻、およびタイムスタンプ型の列を分散キーとして選択しないでください。前述の列は、データ書き込み中にデータの偏りが発生しやすく、書き込みパフォーマンスが低下する可能性があります。ほとんどのクエリは、1 日や 1 か月などの期間に限定されます。この場合、クエリするデータは 1 つのノードにのみ存在する可能性があり、クエリは分散データベースシステム内のすべてのノードの処理能力を活用できません。日付型と時刻型の列は、パーティションキーとして選択することをお勧めします。
ストレージ診断機能を使用して、列が適切な分散キーであるかどうか、およびデータの偏りが発生しているかどうかを確認できます。
ブロードキャストによる分散
レプリケートテーブルを指定します。レプリケートテーブルは、テーブルが属する AnalyticDB for MySQL クラスタの各シャードにデータレプリカを格納します。各レプリケートテーブルには大量のデータを格納しないことをお勧めします。
利点：JOIN クエリを実行する場合、異なるノード間でレプリケートテーブルのデータを送信する必要はありません。これにより、ネットワーク送信のオーバーヘッドが大幅に削減され、高並列シナリオでのクラスタの安定性が向上します。
欠点：レプリケートテーブルで INSERT、UPDATE、および DELETE 操作を実行した後にデータが変更されると、データの整合性を確保するために、これらの変更はクラスタのすべてのノードにブロードキャストされます。ただし、これは全体的な書き込みパフォーマンスに影響します。そのため、レプリケートテーブルを頻繁に作成、削除、または変更しないことをお勧めします。
partition_options （パーティションキーとライフサイクル）
テーブルに分散キーを指定した後に、1 つのシャードに大量のデータが含まれている場合は、シャードをパーティションに分割してデータフィルタリングを高速化し、クエリのパフォーマンスを向上させることができます。
PARTITION BY
パーティションキーを指定します。
構文: PARTITION BY VALUE {(column_name)|(DATE_FORMAT(column_name, 'format'))|(FROM_UNIXTIME(column_name, 'format'))} LIFECYCLE n
パラメーター
column_name: パーティションキーの名前。
PARTITION BY VALUE(column_name)構文では、パーティション分割はcolumn_name列の値に基づいています。パーティションキーには、数値、日時、または数値を指定する文字列のいずれかの型を指定できます。DATE_FORMAT(column_name, 'format'))|FROM_UNIXTIME(column_name, 'format'):DATE_FORMAT()関数またはFROM_UNIXTIME()関数を使用して日時列を特定の日付形式に変換し、データをパーティション分割します。指定された日付形式は、年、月、日のみを %Y、%y、%Y%m、%y%m、%Y%m%d、%y%m%d の形式でサポートします。テーブルの作成後、ALTER TABLE 文を実行することで形式を変更できます。columnが BIGINT、TIMESTAMP、DATETIME、または VARCHAR 型の場合、DATE_FORMAT()関数を使用する必要があります。BIGINT 列の例: 1734278400000（ミリ秒単位の UNIX タイムスタンプ）。TIMESTAMP、DATETIME、または VARCHAR 列の例: 2024-11-26 00:01:02。columnが INT 型の場合、FROM_UNIXTIME()関数を使用する必要があります。例: 1696266000（秒単位の UNIX タイムスタンプ）。
使用上の注意
V3.2.1.0 より前の AnalyticDB for MySQL クラスターの場合、 句を使用してパーティションキーを指定する場合は、
LIFECYCLE nパーティションのライフサイクルを指定するPARTITION BYパラメーターを使用してパーティションのライフサイクルを指定する必要があります。指定しないと、エラーが発生します。V3.2.1.0 以降の AnalyticDB for MySQL クラスターの場合、 句を使用して場合、
LIFECYCLE nパラメーターはオプションPARTITION BYパーティションキーを指定するです。 LIFECYCLE n パラメーターを指定しない場合、パーティションデータは削除されません。テーブルの作成後、パーティションキーを追加したり、パーティションキー列を追加、削除、または変更したりすることはできません。パーティションキーを追加または変更するには、目的のパーティションキーを持つテーブルを作成し、データを新しいテーブルに移行します。詳細については、「ALTER TABLE」をご参照ください。
推奨事項
パーティションキーには日時列を使用することをお勧めします。
パーティションが大きすぎる、または小さすぎると、読み取り/書き込みパフォーマンス、さらにはクラスターの安定性に影響を与える可能性があります。推奨されるパーティションサイズとパーティションフィールドの妥当性の基準については、ストレージ診断トピックの「パーティションテーブルの診断」セクションをご参照ください。
履歴パーティションのデータを頻繁に更新しないことをお勧めします。履歴パーティションのデータを頻繁に更新する場合は、パーティションキーを変更する必要がある場合があります。
LIFECYCLE n
PARTITION BY 句とともに LIFECYCLE n パラメーターを使用する必要があります。このパラメーターを使用して、パーティションのライフサイクルを管理できます。AnalyticDB for MySQL は、パーティションキーの値に基づいてパーティションを降順にソートします。最初の n 個のパーティションは保持され、他のパーティションは削除されます。
V3.2.1.1 より前の AnalyticDB for MySQL クラスターの場合、
LIFECYCLE nパラメーターは、各シャードに最大 n 個のパーティションを保持できることを指定します。パーティションのライフサイクルはシャードレベルで管理されます。ただし、データの分布が不均一である場合、またはデータ量が非常に少ない場合は、特定のシャードに n 個を超えるパーティションが保持される場合があります。V3.2.1.1 以降の AnalyticDB for MySQL クラスターの場合、パーティションのライフサイクルはテーブルレベルで管理されます。
LIFECYCLE nパラメーターは、各テーブルに最大 n 個のパーティションを保持できることを指定します。ただし、AnalyticDB for MySQL クラスターが V3.2.1.1 以降に更新される前に作成されたテーブルの場合、パーティションのライフサイクルはシャードレベルで管理されます。LIFECYCLE nパラメーターは、各シャードに最大 n 個のパーティションを保持できることを指定します。
例
PARTITION BY VALUE (DATE_FORMAT(date, '%Y%m%d')) LIFECYCLE 30 は、パーティション分割中に、date 列のデータが yyyyMMdd 形式に変換され、最大 30 個のパーティションが保持されることを指定します。1 日目から 30 日目までのデータが、パーティション 20231201 からパーティション 20231230 までの対応するパーティションに書き込まれるとします。31 日目にパーティション 20231231 にデータが書き込まれると、最大 30 個のパーティションしか保持できないため、パーティションキーの値が最も小さいパーティション（パーティション 20231201）が自動的に削除されます。
INDEX_ALL（すべての列にインデックスを作成）
STORAGE_POLICY (ストレージポリシー)
Enterprise Edition、Basic Edition、および Data Lakehouse Edition クラスターと、Cluster Edition のためのエラスティックモードの Data Warehouse Edition クラスターでは、データストレージポリシーを指定できます。ストレージポリシーは、読み取り/書き込みパフォーマンスとストレージコストが異なります。
有効な値:
hot (デフォルト): ホットストレージ。テーブル全体のすべてのパーティションのデータは SSD に保存されます。ホットストレージは読み取り/書き込みパフォーマンスが最も優れていますが、ストレージコストが最も高くなります。
cold: コールドストレージ。テーブル全体のすべてのパーティションのデータは Object Storage Service (OSS) に保存されます。ホットストレージと比較して、コールドストレージは読み取り/書き込みパフォーマンスが低いですが、最も低コストのオプションです。
mixed: ホットストレージとコールドストレージの組み合わせ。階層化ストレージとも呼ばれます。このポリシーは、頻繁にアクセスされるデータ (ホットデータ) を SSD に保存し、アクセス頻度の低いデータ (コールドデータ) を OSS に保存することで、ストレージコストを削減し、クエリパフォーマンスを確保します。STORAGE_POLICY パラメーターを mixed に設定する場合は、
PARTITION BY句を使用してパーティションキーを指定し、hot_partition_countパラメーターを使用してホットパーティションの数を指定する必要があります。パーティションキーを指定しない場合、階層化ストレージは有効にならず、データは SSD に保存されます。
例
日付で自動的にパーティション化されたパーティションテーブルを作成する
sale_time ボリュームの日付値で自動的にパーティション化される sales という名前のパーティションテーブルを作成します。
CREATE TABLE sales (
sale_id BIGINT NOT NULL COMMENT '注文 ID',
customer_id VARCHAR NOT NULL COMMENT '顧客 ID',
phone_num BIGINT NOT NULL COMMENT '電話番号',
revenue DECIMAL(15, 2) COMMENT '合計金額',
sale_time TIMESTAMP NOT NULL COMMENT '注文時間',
PRIMARY KEY (sale_time,sale_id)
)
DISTRIBUTED BY HASH(sale_id)
PARTITION BY VALUE(DATE_FORMAT(sale_time, '%Y%m%d')); パーティションライフサイクルが設定されたパーティションテーブルを作成する
customer という名前のパーティションテーブルを作成します。login_time、customer_id、および phone_num を複合プライマリキーとして、customer_id を分散キーとして、login_time をパーティションキーとして指定します。パーティションライフサイクルを 30 に設定します。
すべてのパーティションは、login_time パーティションキーの値に基づいて降順にソートされます。最初の 30 個のパーティションのみが保持されます。31 番目のパーティションにデータが書き込まれると、パーティションキーの値が最も小さいパーティションが自動的に削除されます。
1 日目（login_time 値 20231201）から 30 日目（login_time 値 20231230）までのデータが、パーティション 20231201 からパーティション 20231230 までの対応するパーティションに書き込まれるとします。31 日目に login_time 値 20231231 のデータがデータベースに書き込まれると、login_time 値が最も小さいパーティション（パーティション 20231201）が自動的に削除されます。このようにして、過去 30 日以内のデータのみが保持されます。
CREATE TABLE customer (
customer_id BIGINT NOT NULL COMMENT '顧客 ID',
customer_name VARCHAR NOT NULL COMMENT '顧客名',
phone_num BIGINT NOT NULL COMMENT '電話番号',
city_name VARCHAR NOT NULL COMMENT '市',
sex INT NOT NULL COMMENT '性別',
id_number VARCHAR NOT NULL COMMENT 'ID カード番号',
home_address VARCHAR NOT NULL COMMENT '自宅住所',
office_address VARCHAR NOT NULL COMMENT '勤務先住所',
age INT NOT NULL COMMENT '年齢',
login_time TIMESTAMP NOT NULL COMMENT 'ログオン時間',
PRIMARY KEY (login_time,customer_id,phone_num)
)
DISTRIBUTED BY HASH(customer_id)
PARTITION BY VALUE(DATE_FORMAT(login_time, '%Y%m%d')) LIFECYCLE 30
COMMENT '顧客情報テーブル'; 非パーティションテーブルを作成する
分散キーまたはパーティションキーのない非パーティションテーブルを作成する
プライマリキーはあるが分散キーがないテーブルを作成する場合、AnalyticDB for MySQL はプライマリキーを分散キーとして自動的に使用します。
CREATE TABLE orders (
order_id BIGINT NOT NULL COMMENT '注文 ID',
customer_id INT NOT NULL COMMENT '顧客 ID',
order_status VARCHAR(1) NOT NULL COMMENT '注文ステータス',
total_price DECIMAL (15, 2) NOT NULL COMMENT '合計金額',
order_date DATE NOT NULL COMMENT '注文日',
PRIMARY KEY(order_id,order_date)
);テーブルの作成に使用された文をクエリし、プライマリキー列 order_id と order_date が分散キーとして使用されていることを確認します。
SHOW CREATE TABLE orders;+---------+-----------------------------------------------------------------------------------------------------------------------------------------------+
| Table | Create Table |
+---------+-----------------------------------------------------------------------------------------------------------------------------------------------+
| orders | CREATE TABLE `orders` ( |
| | 'order_id' bigint NOT NULL COMMENT '注文 ID', |
| | 'customer_id' int NOT NULL COMMENT '顧客 ID', |
| | 'order_status' varchar(1) NOT NULL COMMENT '注文ステータス', |
| | 'total_price' decimal(15, 2) NOT NULL COMMENT '合計金額', |
| | 'order_date' date NOT NULL COMMENT '注文日', |
| | PRIMARY KEY (`order_id`,`order_date`) |
| | ) DISTRIBUTED BY HASH(`order_id`,`order_date`) INDEX_ALL='Y' STORAGE_POLICY='HOT' ENGINE='XUANWU' TABLE_PROPERTIES='{"format":"columnstore"}' |
+---------+-----------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.04 sec)プライマリキーまたは分散キーのない非パーティションテーブルを作成する
プライマリキーまたは分散キーのないテーブルを作成する場合、AnalyticDB for MySQL は __adb_auto_id__ 列をテーブルに追加し、その列をプライマリキーおよび分散キーとして使用します。
CREATE TABLE orders_new (
order_id BIGINT NOT NULL COMMENT '注文 ID',
customer_id INT NOT NULL COMMENT '顧客 ID',
order_status VARCHAR(1) NOT NULL COMMENT '注文ステータス',
total_price DECIMAL (15, 2) NOT NULL COMMENT '合計金額',
order_date DATE NOT NULL COMMENT '注文日'
);テーブルの作成に使用された文をクエリし、__adb_auto_id__ という名前の自動インクリメント列がテーブルに自動的に追加され、プライマリキーおよび分散キーとして使用されていることを確認します。
SHOW CREATE TABLE orders_new;+-------------+-----------------------------------------------------------------------------------------------------------------------------------------------+
| Table | Create Table |
+-------------+-----------------------------------------------------------------------------------------------------------------------------------------------+
| orders_new | CREATE TABLE `orders_new` ( |
| | `__adb_auto_id__` bigint AUTO_INCREMENT, |
| | 'order_id' bigint NOT NULL COMMENT '注文 ID', |
| | 'customer_id' int NOT NULL COMMENT '顧客 ID', |
| | 'order_status' varchar(1) NOT NULL COMMENT '注文ステータス', |
| | 'total_price' decimal(15, 2) NOT NULL COMMENT '合計金額', |
| | 'order_date' date NOT NULL COMMENT '注文日', |
| | PRIMARY KEY (`__adb_auto_id__`) |
| | ) DISTRIBUTED BY HASH(`__adb_auto_id__`) INDEX_ALL='Y' STORAGE_POLICY='HOT' ENGINE='XUANWU' TABLE_PROPERTIES='{"format":"columnstore"}' |
+-------------+-----------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.04 sec)プライマリキーと分散キーはあるがパーティションキーのない非パーティションテーブルを作成する
supplier_id 自動インクリメント列を分散キーとして使用し、supplier_id 値のハッシュ値に基づいてシャーディングされる supplier という名前のテーブルを作成します。
CREATE TABLE supplier (
supplier_id BIGINT AUTO_INCREMENT PRIMARY KEY,
supplier_name VARCHAR,
address INT,
phone VARCHAR
)
DISTRIBUTED BY HASH(supplier_id);ストレージポリシーを指定する
コールドストレージポリシーを指定する
CREATE TABLE item (
order_id BIGINT NOT NULL,
item_id INT NOT NULL,
quantity DECIMAL(15, 2) NOT NULL,
discount DECIMAL(15, 2) NOT NULL,
shipdate DATE NOT NULL,
PRIMARY KEY (order_id,item_id,shipdate)
)
DISTRIBUTED BY HASH(item_id)
PARTITION BY VALUE(date_format(shipdate, '%Y%m')) LIFECYCLE 200
STORAGE_POLICY='COLD';ホットストレージポリシーを指定する
CREATE TABLE item (
order_id BIGINT NOT NULL,
item_id INT NOT NULL,
quantity DECIMAL(15, 2) NOT NULL,
discount DECIMAL(15, 2) NOT NULL,
shipdate DECIMAL NOT NULL,
PRIMARY KEY (order_id,item_id,shipdate)
)
DISTRIBUTED BY HASH(item_id)
PARTITION BY VALUE(date_format(shipdate, '%Y%m')) LIFECYCLE 200
STORAGE_POLICY='HOT';階層型ストレージポリシーを指定し、ホットパーティションの数を 16 に設定する
CREATE TABLE item (
order_id BIGINT NOT NULL,
item_id INT NOT NULL,
quantity DECIMAL(15, 2) NOT NULL,
discount DECIMAL(15, 2) NOT NULL,
shipdate DATE NOT NULL,
PRIMARY KEY (order_id,item_id,shipdate)
)
DISTRIBUTED BY HASH(item_id)
PARTITION BY VALUE(date_format(shipdate, '%Y%m')) LIFECYCLE 200
STORAGE_POLICY='MIXED' HOT_PARTITION_COUNT=16;特定の列に通常のインデックスを作成する
id 列と date 列に通常のインデックスを作成します。
CREATE TABLE index_tb (
id INT,
sales DECIMAL(15, 2),
date DATE,
INDEX (id),
INDEX (date),
PRIMARY KEY (id)
)
DISTRIBUTED BY HASH(id);フルテキストインデックスを指定する
content 列に fidx_c という名前のフルテキストインデックスを作成します。
CREATE TABLE fulltext_tb (
id INT,
content VARCHAR,
keyword VARCHAR,
FULLTEXT INDEX fidx_c(content),
PRIMARY KEY (id)
)
DISTRIBUTED BY HASH(id);フルテキストインデックスを作成および変更する方法については、『フルテキストインデックスを作成する』トピックの「既存のテーブルのフルテキストインデックスを作成する」セクションをご参照ください。
フルテキスト検索については、「フルテキスト検索」をご参照ください。
ベクタインデックスを指定する
short_feature という名前の ARRAY<SMALLINT> 型の 4 次元ベクタ列と、float_feature という名前の ARRAY<FLOAT> 型の 4 次元ベクタ列を持つテーブルを作成します。
テーブルのベクタ列に、short_feature_index と float_feature_index という名前のベクタインデックスを作成します。
CREATE TABLE fact_tb (
xid BIGINT NOT NULL,
cid BIGINT NOT NULL,
uid VARCHAR NOT NULL,
vid VARCHAR NOT NULL,
wid VARCHAR NOT NULL,
short_feature array<smallint>(4),
float_feature array<float>(4),
ann index short_feature_index(short_feature),
ann index float_feature_index(float_feature),
PRIMARY KEY (xid, cid, vid)
)
DISTRIBUTED BY HASH(xid) PARTITION BY VALUE(cid) LIFECYCLE 4;ベクタインデックスとベクタ検索の詳細については、「ベクタ検索」をご参照ください。
外部キーインデックスを指定する
store_returns という名前のテーブルを作成します。FOREIGN KEY 句を使用して、store_returns テーブルの sr_item_sk 列を customer テーブルのプライマリキー列 customer_id に関連付けます。
CREATE TABLE store_returns (
sr_sale_id BIGINT NOT NULL PRIMARY KEY,
sr_store_sk BIGINT,
sr_item_sk BIGINT NOT NULL,
FOREIGN KEY (sr_item_sk) REFERENCES customer (customer_id)
);JSON 配列インデックスを指定する
テーブルを作成し、vj 列に idx_vj という名前の JSON 配列インデックスを作成します。
CREATE TABLE json(
id INT,
vj JSON,
INDEX idx_vj(vj->'$[*]')
)
DISTRIBUTED BY HASH(id);JSON 配列インデックスの作成および変更方法については、JSON インデックス トピックの「JSON 配列インデックスを作成する」セクションと、ALTER TABLE トピックの「JSON 配列インデックス」セクションをご参照ください。
よくある質問
列属性と制約
分散キー、パーティションキー、およびライフサイクル
分散キーはシャーディングで使用されます。分散キーのハッシュ値に基づいて、テーブル内のデータは異なるシャードに分散されます。パーティションキーはパーティション分割で使用されます。シャード内では、データはパーティションキーの値に基づいて異なるパーティションにさらに分散されます。次の図は、シャーディングとパーティション分割の仕組みを示しています。
インデックス
列指向ストレージ
その他
一般的なエラーとトラブルシューティング
参照
データのテーブルへの書き込み方法については、「INSERT INTO」をご参照ください。
クエリ結果のテーブルへの挿入方法、またはクエリ結果によるテーブル内の特定のデータの上書き方法については、「INSERT SELECT FROM」または「INSERT OVERWRITE SELECT」をご参照ください。
ApsaraDB RDS、MaxCompute、OSS などのデータソースから AnalyticDB for MySQL にデータをインポートする方法については、「データインポート」をご参照ください。