すべてのプロダクト
Search
ドキュメントセンター

AnalyticDB:CREATE TABLE 文を使用してパーティションテーブルとレプリケートテーブルを作成する

最終更新日:Dec 11, 2025

このトピックでは、AnalyticDB for MySQLCREATE TABLE 文を使用してパーティションテーブルとレプリケートテーブルを作成する方法、およびテーブルの分散キー、パーティションキー、インデックス、パーティションのライフサイクル、ホットデータとコールドデータの階層型ストレージポリシーを指定する方法について説明します。

テーブルのデータ分散スキーム

次の図は、テーブルを作成する前に理解しておく必要がある、シャード、パーティション、クラスター化インデックスなどの概念を示しています。

構文

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_name

テーブルの名前。テーブル名は 1~127 文字で、文字、数字、アンダースコア (_) を使用できます。テーブル名は文字またはアンダースコア (_) で始まる必要があります。

db_name.table_name 形式を使用して、データベース内に作成するテーブルを指定できます。

column_name

テーブルに追加する列の名前。列名は 1~127 文字で、文字、数字、アンダースコア (_) を使用できます。列名は文字またはアンダースコア (_) で始まる必要があります。

column_type

列のデータ型。AnalyticDB for MySQL がサポートするデータ型については、「基本データ型」および「複合データ型」をご参照ください。

COMMENT

列またはテーブルのコメント。

column_attributes (DEFAULT | AUTO_INCREMENT)

DEFAULT {constant | CURRENT_TIMESTAMP}

列のデフォルト値を指定します。デフォルト値は定数または CURRENT_TIMESTAMP 関数にすることができます。他の関数や可変式はサポートされていません。

値が指定されていない場合、列のデフォルト値は NULL です。

AUTO_INCREMENT

自動インクリメント列を指定します。自動インクリメント列は BIGINT 型である必要があります。

AnalyticDB for MySQL は自動インクリメント列に一意の値を割り当てます。ただし、これらの値は連続していない場合があり常に 1 から始まるとは限りません

重要
  • 自動インクリメント列を含むテーブルにデータを挿入する場合、列名を明示的に指定することを推奨します。例: INSERT INTO table (column1,column2) VALUES (value1,value2)。これにより、列の数や順序の不一致によって引き起こされる Insert query has mismatched column sizes のようなエラーメッセージを防ぐことができます。

  • 分散システムの性質上、ETL プロセス中に INSERT INTO SELECT を介してデータが書き込まれる場合、自動インクリメント列は単一の ETL ジョブ内でのみ一意性を保証し、複数の ETL ジョブにまたがる一意性は保証しません。

column_constraints (NOT NULL | PRIMARY KEY)

NOT NULL

NOT NULL 列を指定します。これには NULL 値を含めることはできません。NULL として指定された列、または NOT NULL として指定されていない列には NULL 値を含めることができます。

PRIMARY KEY

プライマリキーを指定します。列制約を使用して、プライマリキーとして指定できる列は 1 つだけです。たとえば、id BIGINT NOT NULL PRIMARY KEY を使用して id 列をプライマリキーとして指定できます。複数の列をプライマリキーとして指定するには、table_constraints で複合プライマリキーを使用します。

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 ジョブのパーティション再構築速度が低下します。

CLUSTERED KEY

クラスター化インデックスを指定します。クラスター化インデックスはパーティションレベルで設定されます。これは、データが格納される物理的な順序を決定します。パーティション内のデータは、クラスター化インデックスの値に基づいてソートされ、順番に格納されます。デフォルトでは、データは昇順でソートおよび格納されます。クラスター化インデックスのキー値が同じまたは類似しているデータレコードは、同じまたは隣接するデータブロックに格納されます。範囲クエリまたは等価フィルタリングでは、クラスター化インデックスを使用すると、ディスク 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 を超える文字列など) をクラスター化インデックスで使用しないことを推奨します。

FULLTEXT INDEX | FULLTEXT KEY

フルテキストインデックスを指定します。

構文とパラメーター

構文[FULLTEXT [INDEX|KEY] [index_name] (column_name) [index_option]] [,...]

パラメーター

FOREIGN KEY

外部キーインデックスを指定します。外部キーインデックスは、不要な JOIN を排除するために使用されます。

構文とパラメーター

サポートされるバージョン

V3.1.10 以降AnalyticDB for MySQL クラスターのみが FOREIGN KEY 句をサポートします。

説明

AnalyticDB for MySQL クラスターのマイナーバージョンを表示および更新するには、AnalyticDB for MySQL コンソールにログインし、クラスター情報 ページの 構成情報 セクションに移動します。

構文[[CONSTRAINT [symbol]] FOREIGN KEY (fk_column_name) REFERENCES pk_table_name (pk_column_name)][,...]

パラメーター

  • symbol:外部キー制約の名前。名前はテーブル内で一意である必要があります。このパラメーターはオプションです。このパラメーターを指定しない場合、パーサは自動的に外部キー列の名前に _fk を付けたものを外部キー制約の名前として使用します。

  • fk_column_name:外部キー列の名前。列はすでに存在している必要があります。

  • pk_table_name:プライマリテーブルの名前。プライマリテーブルはすでに存在している必要があります。

  • pk_column_name:外部キー制約列の名前。これはプライマリテーブルのプライマリキー列です。列はすでに存在している必要があります。

注意事項

  • 各テーブルには複数の外部キーインデックスを設定できます。

  • 外部キーインデックスは、FOREIGN KEY (sr_item_sk, sr_ticket_number) REFERENCES store_sales(ss_item_sk,d_date_sk) のように複数の列で構成することはできません。

  • AnalyticDB for MySQL はデータ制約をチェックしません。プライマリテーブルのプライマリキーと関連テーブルの外部キーとの間のデータ制約関係をチェックする必要があります。

  • 外部テーブルに外部キー制約を追加することはできません。

ANN INDEX

ベクトルインデックスを指定します。

:XUANWU_V2 テーブルにはベクトルインデックスを作成できません。

構文とパラメーター

構文[ANN INDEX [index_name] (column_name,...) [index_option]] [,...]

パラメーター

  • index_name:ベクトルインデックスの名前。

  • column_name:ベクトル列の名前。ベクトル列は、ARRAY<FLOAT>、ARRAY<SMALLINT>、ARRAY<BYTE> のいずれかの型である必要があります。ベクトル次元を指定する必要があります。たとえば、次の構文を使用して、feature という名前の ARRAY<FLOAT> 型の 4 次元ベクトル列を作成できます:feature array<float>(4)

  • index_option:ベクトルインデックスの属性。

    • algorithm:ベクトル間の距離を計算する数式で使用されるアルゴリズム。値を HNSW_PQ に設定します。これは、ベクトル次元に敏感で、テーブルあたり 100 万から 1,000 万のレコードを含む中規模のデータセットに適しています。

    • dis_function:ベクトル間の距離を計算するために使用される数式。値を SquaredL2 に設定します。計算式:(x1 - y1)^2 + (x2 - y2)^2 + ...

JSON INDEX

JSON インデックスまたは JSON 配列インデックスを指定します。

構文とパラメーター

JSON インデックス

サポートされるバージョン

  • V3.1.5.10 以降の AnalyticDB for MySQL クラスターでは、テーブルを作成しても JSON インデックスは自動的に作成されません。JSON インデックスを手動で作成する必要があります。

  • V3.1.5.10 より前の AnalyticDB for MySQL クラスターでは、テーブルを作成すると JSON 列に対して JSON インデックスが自動的に作成されます。

説明

AnalyticDB for MySQL クラスターのマイナーバージョンを表示および更新するには、AnalyticDB for MySQL コンソールにログインし、クラスター情報 ページの 構成情報 セクションに移動します。

構文[INDEX [index_name] (column_name|column_name->'$.json_path')]

パラメーター

  • index_name:インデックスの名前。

  • column_name | column_name->'$.json_path':

    • column_name:JSON インデックスを作成する列の名前。

    • column_name->'$.json_path':JSON 列とそのプロパティキー。各 JSON インデックスは、JSON 列の 1 つのプロパティキーのみを対象とします。

      重要
      • V3.1.6.8 以降の AnalyticDB for MySQL クラスターのみが column_name->'$.json_path パラメーターをサポートします。

      • JSON 列にすでにインデックスがある場合、JSON 列のプロパティキーにインデックスを作成する前に、JSON 列のインデックスを削除する必要があります。

JSON 配列インデックス

サポートされるバージョン

V3.1.10.6 以降の AnalyticDB for MySQL クラスターのみが JSON 配列インデックスをサポートします。

説明

AnalyticDB for MySQL クラスターのマイナーバージョンを表示および更新するには、AnalyticDB for MySQL コンソールにログインし、クラスター情報 ページの 構成情報 セクションに移動します。

構文[INDEX [index_name] (column_name->'$[*]')]

パラメーター

  • index_name:インデックスの名前。

  • column_name->'$[*]': JSON 配列インデックスを作成する列の名前。たとえば、vj->'$[*]' は vj 列に 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 つのノードにしか存在しない可能性があり、クエリは分散データベースシステムのすべてのノードの処理能力を活用できません。日付と時刻の型の列をパーティションキーとして選択することを推奨します。

  • ストレージ診断機能を使用して、列が適切な分散キーであるかどうか、およびデータスキューが発生しているかどうかを確認できます。

DISTRIBUTED BY BROADCAST

レプリケートテーブルを指定します。レプリケートテーブルは、テーブルが属する AnalyticDB for MySQL クラスターの各シャードにデータレプリカを格納します。各レプリケートテーブルに大量のデータを格納しないことを推奨します。

利点:JOIN クエリを実行する際、レプリケートテーブルのデータを異なるノード間で転送する必要がありません。これにより、ネットワーク転送のオーバーヘッドが大幅に削減され、高並行性シナリオでのクラスターの安定性が向上します。

欠点:レプリケートテーブルで INSERT、UPDATE、DELETE 操作を実行した後にデータが変更されると、これらの変更はデータ整合性を確保するためにクラスターのすべてのノードにブロードキャストされます。ただし、これにより全体の書き込みパフォーマンスが影響を受けます。したがって、レプリケートテーブルを頻繁に作成、削除、または変更しないことを推奨します。

partition_options (パーティションキーとライフサイクル)

テーブルに分散キーを指定した後、単一のシャードに大量のデータが含まれる場合、シャードをパーティションに分割してデータフィルタリングを高速化し、クエリパフォーマンスを向上させることができます。

利点

  • パーティショニングは、次の理由によりデータフィルタリングを高速化し、クエリパフォーマンスを向上させます:

    • パーティションプルーニング機能を使用してクエリ速度を向上させます。パーティションプルーニング機能により、システムはクエリに関連するデータを含むパーティションのみをスキャンできます。これにより、クエリ速度が向上します。

    • インデックススキャンパフォーマンスを向上させます。5,000 万行など、過剰な行数を含むテーブルがパーティション分割されていない場合、インデックススキャンの効率は低くなります。テーブルがパーティション分割されている場合、各パーティションにインデックスが作成されます。これにより、より効率的なインデックススキャンが可能になります。

    • BUILD ジョブの効率を向上させます。BUILD ジョブを使用して、リアルタイムで書き込まれたデータを既存データに変換できます。このプロセス中に、システムはパーティションとインデックスを作成し、冗長なデータをクリアします。インデックスは BUILD ジョブが完了した後にのみ有効になります。テーブルがパーティション分割されていない場合、各 BUILD ジョブでテーブル全体がスキャンされます。テーブルに含まれるレコードが多いほど、プロセスに時間がかかり、新しいインデックスが有効になるのが遅くなります。これはクエリパフォーマンスに影響します。テーブルがパーティション分割されている場合、各 BUILD ジョブでデータ変更があったパーティションのみがスキャンされます。これにより、BUILD ジョブの効率が向上します。

  • パーティショニングはデータライフサイクル管理を容易にします。

  • パーティショニングは、異なるストレージポリシーに基づいてホットデータとコールドデータの階層型ストレージを実装するのに役立ちます。

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 列の値に基づいて行われます。パーティションキーは、数値datetime、または数値を指定する文字列のいずれかの型にすることができます。

  • DATE_FORMAT(column_name, 'format'))|FROM_UNIXTIME(column_name, 'format')DATE_FORMAT() または FROM_UNIXTIME() 関数を使用して datetime 列を特定の日付形式に変換し、データをパーティション分割します。指定された日付形式は、%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 クラスターでは、PARTITION BY 句を使用してパーティションキーを指定する場合、LIFECYCLE n パラメーターを使用してパーティションのライフサイクルを指定する必要があります。そうしないと、エラーが発生します。

  • AnalyticDB for MySQL V3.2.1.0 以降のクラスターでは、PARTITION BY 句を使用してパーティションキーを指定する場合、LIFECYCLE n パラメーターは任意です。 LIFECYCLE n パラメーターを指定しない場合、パーティションデータは削除されません。

  • テーブルが作成された後、パーティションキーを追加したり、パーティションキー列を追加、削除、または変更したりすることはできません。パーティションキーを追加または変更するには、目的のパーティションキーを持つテーブルを作成し、データを新しいテーブルに移行します。詳細については、「ALTER TABLE」をご参照ください。

推奨事項

  • datetime 列をパーティションキーとして使用することを推奨します。

  • パーティションが大きすぎたり小さすぎたりすると、読み取り/書き込みパフォーマンスやクラスターの安定性に影響を与える可能性があります。推奨されるパーティションサイズとパーティションフィールドの妥当性の基準については、「ストレージ診断」トピックの「パーティションテーブルの診断」セクションをご参照ください。

  • 既存のパーティションのデータを頻繁に更新しないことを推奨します。既存のパーティションのデータを頻繁に更新する場合、パーティションキーを変更する必要がある場合があります。

LIFECYCLE n

LIFECYCLE n パラメーターは PARTITION BY 句と一緒に使用する必要があります。このパラメーターを使用して、パーティションのライフサイクルを管理できます。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 (すべての列のインデックス)

テーブルのすべての列にインデックスを作成するかどうかを指定します。

有効値

  • Y:すべての列にインデックスを作成します。XUANWU テーブルの場合、デフォルト値は Y です。

  • N:プライマリキーにのみインデックスを作成します。XUANWU_V2 テーブルの場合、デフォルト値は N です。

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 に格納されます。

    階層型ストレージの例

hot_partition_count (ホットパーティション)

STORAGE_POLICY パラメーターを mixed に設定する場合、hot_partition_count=n (n は正の整数) を使用してホットパーティションの数を指定する必要があります。AnalyticDB for MySQL は、パーティションキーの値に基づいてレコードを降順にソートします。最初の n 個のパーティションはホットパーティションであり、その他のパーティションはコールドパーティションです。

説明

STORAGE_POLICY パラメーターを mixed 以外の値に設定し、hot_partition_count=n を使用すると、エラーが発生します。

block_size (データブロック)

データブロックは、データの読み書きを行う最小の I/O 単位です。BLOCK_SIZE パラメーターは、列指向ストレージの各データブロックに格納される行数を指定します。このパラメーターは、各 I/O 操作で読み取られる行数を決定し、クエリの特性に基づいてクエリパフォーマンスに影響を与えます。たとえば、ポイントクエリに対して BLOCK_SIZE が大きな値に設定されている場合、ストレージシステムによるブロックの読み取りが非効率になります。この場合、BLOCK_SIZE の値を適切に小さくすることができます。

デフォルト値:

  • レプリケートテーブルのデフォルト値:4096。

  • 32 コア未満のスタンドアロン版の弾力性モードの AnalyticDB for MySQL Data Warehouse Edition クラスターのデフォルト値:8192。

  • その他の場合のデフォルト値:32760。BLOCK_SIZE のデフォルト値が 32760 の場合、SHOW CREATE TABLE 文を実行しても BLOCK_SIZE は表示されません。

重要

列指向ストレージに慣れていない場合は、BLOCK_SIZE の値を変更しないことを推奨します。

ENGINE (ストレージエンジン)

AnalyticDB for MySQL 内部テーブルのストレージエンジンタイプを指定します。ストレージエンジンを使用して履歴データ分析を行うことができます。

  • V3.2.2.0 より前の AnalyticDB for MySQL クラスターでは、値を XUANWU に設定します。ENGINE パラメーターを明示的に指定しない場合、XUANWU が使用されます。

    重要

    V3.1.9.5 より前のバージョンでは、内部テーブルを作成する際に ENGINE='XUANWU' を明示的に指定する場合、table_properties='{"format":"columnstore"}' も明示的に指定する必要があります。そうしないと、テーブルの作成に失敗します。

  • V3.2.2.0 以降の AnalyticDB for MySQL クラスターの有効値:

    • RC_DDL_ENGINE_REWRITE_XUANWUV2 が true に設定されている場合:XUANWU_V2。

    • RC_DDL_ENGINE_REWRITE_XUANWUV2 が false に設定されている場合:XUANWU_V2 および XUANWU。

    SHOW ADB_CONFIG KEY=RC_DDL_ENGINE_REWRITE_XUANWUV2; 文を実行して、このパラメーターの値をクエリできます。また、クラスターまたはテーブルレベルで RC_DDL_ENGINE_REWRITE_XUANWUV2 の値を変更することもできます。

AS query_expr (CTAS)

CREATE TABLE AS query_expr を使用してテーブルを作成し、クエリされたデータを新しいテーブルに書き込むことができます。詳細については、「CREATE TABLE AS SELECT (CTAS)」をご参照ください。

日付で自動的にパーティション分割されるパーティションテーブルの作成

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_timecustomer_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 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='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);

クラスター化インデックスの指定

quantity 列に clustered_index という名前のクラスター化インデックスを作成します。

CREATE TABLE clustered (
  product_id INT,
  product_name VARCHAR,
  quantity INT,        
  price DECIMAL(10, 2),
  CLUSTERED KEY INDEX clustered_index(quantity)
)
DISTRIBUTED BY HASH(product_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);

フルテキストインデックスの作成と変更方法については、「フルテキストインデックスの作成」をご参照ください。

全文検索については、「全文検索」をご参照ください。

ベクトルインデックスの指定

ARRAY<SMALLINT> 型の 4 次元ベクトル列 short_feature と、ARRAY<FLOAT> 型の 4 次元ベクトル列 float_feature を持つテーブルを作成します。

テーブルのベクトル列に 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 配列インデックス」セクションをご参照ください。

よくある質問

列の属性と制約

自動インクリメント列は常に 1 から始まりますか?すべての値は一意ですか?

自動インクリメント列の値は連続していない場合があり常に 1 から始まるとは限りません。ただし、自動インクリメント列のすべての値は一意です。

分散キー、パーティションキー、およびライフサイクル

分散キーとパーティションキーの違いは何ですか?

分散キーはシャーディングで使用されます。分散キーのハッシュ値に基づいて、テーブル内のデータは異なるシャードに分散されます。パーティションキーはパーティショニングで使用されます。シャード内で、データはパーティションキーの値に基づいてさらに異なるパーティションに分散されます。次の図は、シャーディングとパーティショニングの仕組みを示しています。

テーブルを作成する際に分散キーを指定する必要がありますか?

  • パーティションテーブルを作成する場合、分散キーを指定する必要はありません。プライマリキーを指定し、分散キーを指定しない場合、AnalyticDB for MySQL は自動的にプライマリキーを分散キーとして使用します。プライマリキーまたは分散キーを指定しない場合、AnalyticDB for MySQL は自動的にテーブルに __adb_auto_id__ 列を追加し、その列を分散キーおよびプライマリキーとして使用します。

  • レプリケートテーブルを作成する場合、分散キーを指定する必要はありません。ただし、DISTRIBUTED BY BROADCAST 句を使用して、AnalyticDB for MySQL クラスターの各ストレージノードがデータの完全なコピーを格納するように指定する必要があります。

クラスター仕様を変更すると、シャードの数は影響を受けますか?

いいえ、シャードの数はクラスター仕様の変更による影響を受けません。

テーブルのパーティション情報をクエリするにはどうすればよいですか?

次の文を実行して、テーブルのパーティション情報をクエリできます:

SELECT partition_id, --パーティションの名前。
 row_count, -- パーティション内の行の総数。
 local_data_size, -- パーティションのローカルデータストレージ。
 index_size, -- パーティションインデックスのサイズ。
 pk_size, -- パーティションのプライマリキーインデックスのサイズ。
 remote_data_size -- パーティションのリモートデータストレージ。
FROM information_schema.kepler_partitions
WHERE schema_name = '$DB'
 AND table_name ='$TABLE' 
 AND partition_id > 0;

パーティションテーブルを作成した後にパーティション情報を表示できないのはなぜですか?

パーティションテーブルを作成した後にパーティション情報を表示できない理由は次のとおりです:

  • テーブルにデータが書き込まれていません。テーブルを作成する際、パーティションキーを指定してパーティショニングルールを設定するだけです。パーティショニングはパーティションキーの値に基づいて実行されます。テーブルにデータが書き込まれていない場合、パーティションキーの値は空であり、パーティションは作成されません。

  • パーティションの BUILD ジョブが完了していません。パーティションはリアルタイムで作成されません。テーブルの BUILD ジョブが完了した後にのみ、パーティション情報を表示できます。

解決策:

テーブルにデータを書き込み、BUILD ジョブが完了するのを待ちます。その後、パーティション情報を表示できます。

特定のパーティションのデータをクエリするにはどうすればよいですか?

WHERE <partition_key_name> = '<partition_key_value>' 句を使用して、特定のパーティションのデータをクエリできます。次の構文はサポートされていません:SELECT * FROM table PARTITION(202304)

例:

order_date 列でパーティション分割された orders_demo という名前のテーブルを作成します。

CREATE TABLE orders_demo (
  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) 
PARTITION BY VALUE(date_format(order_date, '%Y%m')) LIFECYCLE 30 ;

テーブルに 10 行のデータを挿入します。

INSERT INTO orders_demo (order_id, customer_id, order_status, total_price, order_date)
VALUES
  (1001, 1, 'C', 150.75, '2023-10-01'),
  (1002, 2, 'P', 200.50, '2023-10-01'),
  (1003, 3, 'S', 99.99, '2023-10-01'),
  (1004, 4, 'C', 300.00, '2023-10-01'),
  (1005, 5, 'P', 450.25, '2023-10-02'),
  (1006, 6, 'S', 120.00, '2023-10-02'),
  (1007, 7, 'C', 80.50, '2023-10-03'),
  (1008, 8, 'P', 600.00, '2023-10-03'),
  (1009, 9, 'S', 250.75, '2023-10-03'),
  (1010, 10, 'C', 199.99, '2023-10-14');

BUILD 文を実行して、パーティションテーブルを構築します。

BUILD TABLE orders_demo;
テーブルが特定の条件を満たす場合、テーブルでBUILD ジョブが自動的にトリガーされます。この例では、後続のステップを容易にするために、手動でテーブルを構築します。

BUILD ジョブのステータスをクエリします。orders_demo テーブルの BUILD ジョブが完了した場合、status フィールドに FINISH の値が返されます。

SELECT table_name, schema_name, status FROM INFORMATION_SCHEMA.KEPLER_META_BUILD_TASK WHERE table_name='ORDERS_DEMO';

この例では、パーティションキー order_date は DATE 型です。2023-10-01 パーティションのデータをクエリするには、次の文を実行します:

SELECT * FROM orders_demo WHERE order_date='2023-10-01';

パーティションキーが DATETIME 型の場合、WHERE 句を WHERE order_date >= "2023-10-01 00:00:00" and order_date < "2023-10-02 00:00:00" に設定します。サンプル文:

SELECT * FROM orders_demo WHERE order_date >= "2023-10-01 00:00:00" and order_date < "2023-10-02 00:00:00";

パーティションテーブルからデータをクエリする際に、パーティションキーをフィルター条件として指定する必要がありますか?

テーブルにパーティションキーがある場合、パーティションキーをフィルター条件として指定する必要はありません。ただし、特定のパーティションのみがスキャンされるため、パーティションキーをフィルター条件として指定することでクエリパフォーマンスを向上させることができます。

パーティションキーでサポートされているデータ型は何ですか?

パーティションキーは、数値、datetime、または数値を指定する文字列のデータ型にすることができます。他のデータ型はデータ書き込みエラーを引き起こす可能性があります。

次のエラーメッセージは、書き込まれたパーティションキーの値がデータ型の要件を満たしていないことを示します:partition format function error

DATE_FORMAT() および FROM_UNIXTIME() 以外の関数を使用してパーティションキーを指定できますか?

いいえ、他の関数を使用してパーティションキーを指定することはできません。パーティションキーは、PARTITION BY VALUE(column_name)、PARTITION BY VALUE(date_format(column_name, 'format'))、および PARTITION BY VALUE(FROM_UNIXTIME(column,'format')) のいずれかの関数を使用してのみ指定できます。他の関数を使用すると、エラーが発生します。

説明

パーティションキーについては、このトピックの「partition_options (パーティションキーとライフサイクル)」セクションをご参照ください。

パーティションのライフサイクルをクエリするにはどうすればよいですか?

SHOW CREATE TABLE <table_name> 文を実行して、パーティションのライフサイクルを表示できます。パーティションのライフサイクルは、返された結果に表示されます。

LIFECYCLE の値を 30 に設定してデータを 30 日間のみ保持するように設定した後でも、30 日以上保存されているデータをクエリできるのはなぜですか?

30 日以上保存されているデータをクエリできる理由は次のとおりです:

  • 特定のパーティションが期限切れになったばかりで、まだ削除されていません。期限切れのパーティションは、テーブルの BUILD ジョブが完了するまで削除されません。

  • シャードレベルのパーティションライフサイクル管理を使用する V3.2.1.1 より前の AnalyticDB for MySQL クラスターでは、テーブル内のシャードに含まれるパーティション数が LIFECYCLE n パラメーターで指定された数よりも少ないです。この問題は、V3.2.1.1 以降の AnalyticDB for MySQL クラスターで作成されたテーブルでは発生しません。

    根本原因:

    • データが同じシャードに一貫して書き込まれていません。データが日付でパーティション分割されていると仮定します。シャード 1 にはパーティション 20231201 から 20231230 が含まれ、シャード 2 にはパーティション 20231202 から 20231231 が含まれます。両方のシャードのパーティションは、両方のシャードに 30 個のパーティションがあり、LIFECYCLE n パラメーターで指定された値 30 を超えないため、保持されます。したがって、パーティション 20231201 から 20231231 のデータをクエリできます。

    • 長期間、テーブルに新しいデータが書き込まれていません。データが日付でパーティション分割されていると仮定します。シャード 1 にはパーティション 20231201、20231202、20231203、および 20231204 が含まれます。パーティションに新しいデータは書き込まれません。この場合、シャード 1 には 4 つのパーティションしかなく、LIFECYCLE n パラメーターで指定された値 30 を超えません。したがって、パーティションは削除されず、パーティション 20231201 のデータを引き続きクエリできます。

期限切れのパーティションのデータはすぐに削除されますか?

いいえ、パーティションはリアルタイムで作成または削除されません。期限切れのパーティションは、テーブルの BUILD ジョブが完了するまで削除されません。

インデックス

テーブルのクラスター化インデックスをクエリするにはどうすればよいですか?

SHOW CREATE TABLE 文を実行して、テーブルで指定されたクラスター化インデックスをクエリできます。

AnalyticDB for MySQL は一意なインデックスをサポートしていますか?

いいえ、AnalyticDB for MySQL は一意なインデックスをサポートしていません。ただし、AnalyticDB for MySQL のテーブルのプライマリキーインデックスは一意なインデックスであり、プライマリキーの値が一意であることを保証します。

INDEX(column1,column2) を使用して複数の列に複合インデックスを作成できますか?

いいえ、複数の列に複合インデックスを作成することはできません。通常のインデックスには単一の列しか含めることができません。例:INDEX(column1)

列指向ストレージ

CREATE TABLE 文の TABLE_PROPERTIES='{"format":"columnstore"}' 構文は何を意味しますか?

TABLE_PROPERTIES='{"format":"columnstore"}' は、ストレージエンジンが列指向ストレージを使用することを指定します。テーブルを作成する際に構文を変更する必要はありません。

テーブルを作成する際に、特定のパーティションに行指向ストレージを指定し、他のパーティションに列指向ストレージを指定できますか?

いいえ、テーブル内のパーティションに異なるストレージ形式を指定することはできません。

その他

テーブルを作成した後に ALTER TABLE 文を使用して何を変更できますか?

ALTER TABLE 文を実行して、次の変更を行うことができます:

  • 次のパラメーターを変更する:table_name、column_name、column_type、および COMMENT。

  • プライマリキー列を除く列を追加および削除する。

  • デフォルトの列値を変更する。

  • NOT NULL 列制約を NULL に変更する。

  • インデックスを作成および削除する。

  • パーティション関数の日付形式を変更する。

  • パーティションのライフサイクルを変更する。

  • ストレージポリシーを変更する。

テーブルが作成された後、その他の変更はできません。詳細については、「ALTER TABLE」をご参照ください。

各クラスターに作成できるテーブルの数はいくつですか?

AnalyticDB for MySQL クラスターに作成できるテーブルの最大数には、次の制限が適用されます:

  • Enterprise Edition クラスターに作成できる内部テーブルの最大数:80000/(シャード数/予約済みリソースノード数/3)。数式では、シャード数/予約済みリソースノード数/3 の結果は切り上げる必要があります。予約済みリソースノードをさらに追加することで、作成できる内部テーブルの最大数を増やすことができます。

  • Basic Edition クラスターに作成できる内部テーブルの最大数:80000/(シャード数/予約済みリソースノード数)。数式では、(シャード数/予約済みリソースノード数) の結果は切り上げる必要があります。予約済みリソースノードをさらに追加することで、作成できる内部テーブルの最大数を増やすことができます。

  • Enterprise Edition、Basic Edition、および Data Lakehouse Edition クラスターまたは弾力性モードの Data Warehouse Edition クラスターに作成できる外部テーブルの最大数:500,000。

  • Data Lakehouse Edition クラスターに作成できる内部テーブルの最大数:[80000/(シャード数/予約済みストレージリソース量を 24 ACU で割った値)] × 2予約済みストレージリソースをスケールアップすることで、作成できる内部テーブルの最大数を増やすことができます。

  • 弾力性モードの Data Warehouse Edition クラスターに作成できる内部テーブルの最大数:[80000/(シャード数/EIU 数)] × 2。数式では、[シャード数/EIU 数] の結果は切り上げる必要があります。エラスティック I/O ユニット (EIU) をスケールアウトすることで、作成できる内部テーブルの最大数を増やすことができます。

  • 1~20 のノードグループを持つ予約モードの Data Warehouse Edition クラスターに作成できる内部テーブルの最大数:80000/(シャード数/ノードグループ数)。数式では、[シャード数/ノードグループ数] の結果は切り上げる必要があります。ノードグループをさらに追加することで、作成できる内部テーブルの最大数を増やすことができます。

説明

シャードの数をクエリするには、SELECT COUNT(1) FROM information_schema.kepler_meta_shards; 文を実行します。シャードの数を増減することはできません。

AnalyticDB for MySQL のデフォルトの文字セットは何ですか?

AnalyticDB for MySQL はデフォルトの文字セットとして UTF-8 を使用します。これは MySQL の utf8mb4 文字セットに相当します。他の文字セットはサポートされていません。

テーブルが内部テーブルか外部テーブルかを判断するにはどうすればよいですか?

SHOW CREATE TABLE db_name.table_name; 文を実行して、テーブルの DDL 文をクエリできます。DDL 文に ENGINE パラメーターが含まれていない場合、または ENGINE パラメーターの値が XUANWU または XUANWU_V2 の場合、テーブルは内部テーブルです。それ以外の場合、テーブルは外部テーブルです。

一般的なエラーとトラブルシューティング

partition number must larger than 0

原因:パーティションキーを指定しましたが、パーティションのライフサイクルを指定していません。

サンプル文:

CREATE TABLE test (
  id INT COMMENT '',
  name VARCHAR(10) COMMENT '',
  PRIMARY KEY (id, name)
) 
DISTRIBUTED BY HASH(id) PARTITION BY VALUE(name);

解決策:CREATE TABLE 文でパーティションのライフサイクルを指定します。サンプル文:

CREATE TABLE test (
  id INT COMMENT '',
  name VARCHAR(10) COMMENT '',
  PRIMARY KEY (id, name)
) 
DISTRIBUTED BY HASH(id) PARTITION BY VALUE(name) LIFECYCLE 30;
説明

このエラーは、V3.2.1.0 より前の AnalyticDB for MySQL クラスターでのみ発生します。

Only 204800 partition allowed, the number of existing partition=>196462

原因:クラスター内のパーティション数が AnalyticDB for MySQL の上限である 102,400 を超えています。

次の文を実行して、クラスター内のパーティション数をクエリします:

SELECT count(partition_id)
FROM information_schema.kepler_partitions
WHERE partition_id > 0;

解決策:ALTER TABLE 文を実行して、パーティションの粒度を大きくします。たとえば、粒度を日から月に変更します。

partition column 'XXX' is not found in primary index=> [YYY]

原因:テーブルのプライマリキーにパーティションキーが含まれていません。

サンプル文:

CREATE TABLE test (
  id INT COMMENT '',
  name VARCHAR(10) COMMENT '',
  PRIMARY KEY (id)
) 
DISTRIBUTED BY HASH(id) PARTITION BY VALUE(name) LIFECYCLE 30;

このエラーは、プライマリキーまたは分散キーを指定しない場合にも発生します。テーブルを作成する際にプライマリキーまたは分散キーを指定しない場合、AnalyticDB for MySQL は自動的にテーブルに __adb_auto_id__ 列を追加し、その列をプライマリキーおよび分散キーとして使用します。この場合、プライマリキーには __adb_auto_id__ 列のみが含まれ、パーティションキーは含まれません。したがって、このエラーが発生します。

サンプル文:

CREATE TABLE test (
  id INT COMMENT '',
  name VARCHAR(10) COMMENT ''
) 
PARTITION BY VALUE(name) LIFECYCLE 30;

解決策:プライマリキーにパーティションキーを含めます。

SemanticException:only 5000 table allowed

原因:このエラーは、AnalyticDB for MySQL クラスター内のテーブルの総数が上限を超えた場合に発生します。テーブルの総数には、使用中のテーブルとテーブルのゴミ箱に含まれるテーブルが含まれます。テーブル数の上限は、エディションや仕様によって異なります。詳細については、「制限事項」をご参照ください。

解決策:

unsigned expr not supported

原因:AnalyticDB for MySQL は符号なし数値をサポートしていないため、UNSIGNED 属性をサポートしていません。

解決策:CREATE TABLE 文で列に UNSIGNED 属性を指定しないでください。代わりに、ビジネスコードで非負値制約を実装する必要があります。

関連ドキュメント

  • テーブルにデータを書き込む方法については、「INSERT INTO」をご参照ください。

  • クエリ結果をテーブルに挿入したり、テーブルの特定のデータをクエリ結果で上書きしたりする方法については、「INSERT SELECT FROM」または「INSERT OVERWRITE SELECT」をご参照ください。

  • ApsaraDB RDS、MaxCompute、OSS などのデータソースから AnalyticDB for MySQL にデータをインポートする方法については、「データインポート」をご参照ください。