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

AnalyticDB:CREATE TABLE:パーティションテーブルおよびレプリケートされたテーブルの作成

最終更新日:May 22, 2026

このトピックでは、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

テーブル名は 1~127 文字で、英字またはアンダースコア (_) で始まり、英数字およびアンダースコア (_) のみを含む必要があります。

特定のデータベースにテーブルを作成するには、db_name.table_name 形式を使用します。

column_name

カラム名は 1~127 文字で、英字またはアンダースコア (_) で始まり、英数字およびアンダースコア (_) のみを含む必要があります。

column_type

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

COMMENT

カラムまたはテーブルのコメントです。

カラム属性

DEFAULT {定数 | 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 などのエラーを回避できます。

  • 分散システムにおいて、INSERT INTO SELECT 文を使用してデータを書き込む場合、自動インクリメント機能は単一の ETL プロセス内でのみ一意性を保証します。

カラム制約

NOT NULL

NOT NULL として定義されたカラムでは、値を NULL にすることはできません。カラムが NOT NULL として定義されていない、または NULL として明示的に定義されている場合は、値を NULL にできます。

PRIMARY KEY

カラム制約としてプライマリキーを定義すると、単一カラムに適用されます(例:id BIGINT NOT NULL PRIMARY KEY)。複数のカラムから構成される複合プライマリキーを作成するには、テーブル制約として定義する必要があります。

テーブル制約 (インデックス)

AnalyticDB for MySQL は、通常のインデックス (INDEX)、主キーインデックス、クラスター化インデックス、外部キーインデックス、フルテキストインデックス、ベクターインデックスなど、さまざまな種類のインデックスをサポートしています。テーブルには 1 つ以上のインデックスを設定できます。

INDEX | KEY

通常のインデックスを定義します。INDEX と KEY は同義語です。

  • XUANWU_V2 テーブルの場合、デフォルトで全カラムにインデックスは作成されません。テーブルにプライマリキーが存在する場合、そのキーに対してのみ通常のインデックスがデフォルトで作成されます。

  • XUANWU テーブルの場合、システムはデフォルトで全カラムにインデックスを作成します。ただし、XUANWU テーブル作成時に特定のカラムに対して手動でインデックスを作成した場合(例:INDEX (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プライマリキーを自動的に追加しません

  • テーブル作成後、プライマリキーカラムを追加、削除、または変更することはできません。

チューニングの推奨事項:パフォーマンスを向上させるには、プライマリキーに数値カラムを使用し、キーに含まれるカラム数を最小限に抑えてください。

説明

プライマリキーに多くのカラムを含めると、以下のような問題が発生する可能性があります。

  • データ書き込み時に AnalyticDB for MySQL が重複するプライマリキー値をチェックするため、CPU および I/O リソース消費量が増加します。

  • 主キーインデックスが使用するディスク領域が増加します。主キーインデックスが使用するディスク領域は、スペースの分析 機能で確認できます。

  • BUILD ジョブの処理が遅くなります。

CLUSTERED KEY

クラスター化インデックスを定義します。クラスター化インデックスはパーティションレベルで設定され、データの物理的な格納順序を決定します。各パーティション内では、データはクラスター化インデックスキーの値に基づいてソートされ、デフォルトでは昇順で連続的に格納されます。システムは同じまたは類似のキー値を持つデータを同じまたは隣接したデータブロックに格納します。範囲クエリまたは等価フィルタリングにおいて、クエリ条件がクラスター化インデックスカラムと一致する場合、ストレージエンジンは連続したデータブロックを高速に読み取ることができます。これにより、ディスク I/O が削減され、データ読み取り速度が向上します。

クラスター化インデックス図

利用シーン

クラスター化インデックスは範囲クエリおよび等価フィルタリングの両方に適しています。範囲クエリまたは等価フィルタリングの条件で頻繁に使用されるカラムにクラスター化インデックスを作成することを検討してください。

クエリ条件がクラスター化インデックスカラムと完全または部分的に一致する場合、データ読み取り効率が向上します。たとえば、SaaS アプリケーションではユーザーが通常自分のデータにのみアクセスするため、ユーザー ID をクラスター化インデックスキーとして使用できます。これにより、同じユーザーのデータが同じまたは隣接したデータブロックに連続して格納され、データ読み取りが高速化されます。

基本的な使用方法

  • 各テーブルにはクラスター化インデックスを 1 つだけ設定できます。

  • クラスター化インデックスは単一カラム(例:CLUSTERED KEY index(id))または複数カラム(例:CLUSTERED KEY index(id,name))で作成できます。クラスター化インデックスが複数カラムで構成される場合、システムはまず最初のカラムの値に基づいてデータをソートします。最初のカラムの値が同じ行については、次に 2 番目のカラムの値に基づいてデータをソートします。したがって、CLUSTERED KEY index(id,name)CLUSTERED KEY index(name,id) は異なります。

  • デフォルトでは、クラスター化インデックスは昇順でデータをソートし、昇順クエリに適しています。クエリで降順が必要な場合は、テーブル作成時にクラスター化インデックスを降順に設定してください(例:CLUSTERED KEY index(id) DESC)。テーブルがすでに存在する場合は、既存のクラスター化インデックスを削除してから、降順で新しいインデックスを作成できます。

  • 数十 KB の文字列など、長い値を持つカラムをクラスター化インデックスキーとして使用しないでください。これにより、ソートパフォーマンスが低下する可能性があります。

FULLTEXT INDEX | FULLTEXT KEY

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

構文とパラメーター

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

パラメーター

  • index_name:フルテキストインデックスの名前です。

  • column_name:インデックス対象のカラムです。このカラムのデータの型は VARCHAR である必要があります。

  • index_option:オプションです。フルテキストインデックスのアナライザおよびカスタム辞書を指定します。

FOREIGN KEY

外部キーインデックスを使用して不要な結合を排除します。

構文とパラメーター

バージョン要件

AnalyticDB for MySQL クラスターのカーネルバージョンが 3.1.10 以降である必要があります。

説明

マイナーバージョンの確認および更新を行うには、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)

  • index_option:ベクターインデックスのプロパティです。

    • algorithm:ベクター距離計算のアルゴリズムです。HNSW_PQ のみサポートされています。このアルゴリズムは、テーブルあたり数百万~数千万レコードの中規模データセットで、ベクトル次元に敏感なケースに適しています。

    • dis_function:ベクター距離計算の数式です。SquaredL2 のみサポートされています。数式:(x1-y1)^2+(x2-y2)^2+…

JSON INDEX

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

構文とパラメーター

JSON インデックス

バージョン要件

    説明

    マイナーバージョンの確認および更新を行うには、AnalyticDB for MySQL コンソールクラスター情報ページにある 構成情報セクションに移動してください。

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

    パラメーター

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

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

      JSON 配列インデックス

      バージョン要件

      カーネルバージョン 3.1.10.6 以降を実行しているクラスターでのみ、JSON 配列インデックスがサポートされています。

      説明

      マイナーバージョンの確認および更新を行うには、AnalyticDB for MySQL コンソールクラスター情報ページにある 構成情報セクションに移動してください。

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

      パラメーター

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

      • column_name->'$[*]':JSON 配列インデックスを作成するカラムです。たとえば、vj->'$[*]'vj カラムに JSON 配列インデックスを作成します。

      テーブル属性 (分散キー)

      table_attribute は、テーブルが標準テーブルかレプリケートされたテーブルかを決定します。

      • DISTRIBUTED BY HASH:テーブルが標準テーブルであることを指定します。標準テーブルは分散システムを活用してクエリ効率を向上させます。通常、数千万~数千億行の大容量データを格納できます。

      • DISTRIBUTED BY BROADCAST:テーブルがレプリケートされたテーブルであることを指定します。レプリケートされたテーブルは、クラスター内の各シャードにデータの完全なコピーを格納します。各レプリケートされたテーブルには 20,000 行を超えないようにすることを推奨します。

      DISTRIBUTED BY HASH (column_name,...)

      テーブルの分散キーを指定します。分散キーを持つ標準テーブルはパーティションテーブルとして知られています。AnalyticDB for MySQL は分散キーの値にハッシュ関数を適用し、結果のハッシュ値に基づいて行を異なるシャードに分散させます。これにより、スケーラビリティとクエリパフォーマンスが向上します。

      シャーディング例

      基本的な使用方法

      • 各テーブルには分散キーを 1 つだけ設定できます。

      • 分散キーは 1 つ以上のカラムで構成できます。

      • 分散キーのカラムはプライマリキーに含まれている必要があります。たとえば、分散キーが customerid の場合、プライマリキーにも customerid を含める必要があります。

      注意事項

      • テーブル作成時に分散キーを指定しなかった場合、テーブルにプライマリキーがあるかどうかに基づいて、システムは次のように処理します。

        • テーブルにプライマリキーがある場合、AnalyticDB for MySQL はデフォルトでプライマリキーを分散キーとして使用します。

        • テーブルにプライマリキーがない場合、AnalyticDB for MySQL は自動的に __adb_auto_id__ という名前のカラムを追加し、それをプライマリキーおよび分散キーの両方として使用します。

      • テーブル作成後、分散キーカラムを追加、削除、または変更することはできません。分散キーを変更するには、新しいテーブルを作成してデータを移行する必要があります。

      推奨事項

      • さまざまな複雑なクエリに対応できるよう、分散キーにはできるだけ少ないカラム数を使用してください。

      • クエリ条件で頻繁に使用され、かつ高カーディナリティ(均等に分散された値)を持つカラムを分散キーとして選択してください。良い例としては、トランザクション ID、デバイス ID、ユーザー ID、自動インクリメント列などがあります。ただし、常に定数値でフィルタリングされるカラムは避けてください。たとえば、カラム a が頻繁にクエリされても条件が常に a=3 である場合、分散キーとして使用するとデータスキューが発生し、不適切な選択となります。

      • 結合で使用されるカラムを分散キーとして使用してください。2 つのテーブルを結合する際、同じ分散キー(結合カラム)を共有している場合、同じキー値を持つデータは同じシャードに配置されます。これにより、シャード間でデータを移動することなくローカルで結合操作を実行でき、データ再分配が削減され、クエリパフォーマンスが向上します。たとえば、顧客ごとの注文履歴を表示する必要がある場合は、customer_id を分散キーとして選択できます。

      • 日付、時刻、タイムスタンプカラムを分散キーとして使用しないでください。これらのカラムは書き込み時にデータスキューを引き起こし、書き込みパフォーマンスを低下させる可能性があります。さらに、クエリは通常特定の日付または時間範囲でフィルタリングされます。時間ベースのカラムを分散キーにすると、クエリのすべてのデータが単一ノードに配置され、クラスター全体で並列処理ができなくなります。日付および時刻カラムは代わりにパーティションキーとして使用することを推奨します。

      • ストレージ診断機能を使用して、分散キーが有効かどうかを確認し、データスキューを特定できます。

      DISTRIBUTED BY BROADCAST

      レプリケートされたテーブルを指定します。レプリケートされたテーブルは、クラスター内の各シャードにデータの完全なコピーを格納します。レプリケートされたテーブルには大量のデータを格納しないことを推奨します。

      利点:結合操作中に、レプリケートされたテーブルのデータをシャード間で移動する必要がありません。高同時実行数のシナリオでは、ネットワークオーバーヘッドが大幅に削減され、クラスターの安定性が向上します。

      欠点:レプリケートされたテーブルのデータが変更された場合(INSERT、UPDATE、DELETE 操作による)、変更内容はすべてのシャードにブロードキャストされ、すべてのコピー間でデータ整合性が確保されます。これにより全体的な書き込みパフォーマンスに影響するため、レプリケートされたテーブルの頻繁な変更は避けることを推奨します。

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

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

      パーティションを定義する理由

      • パーティションによりデータフィルタリングが高速化され、クエリパフォーマンスが向上します。

        • パーティションプルーニング。クエリは関連するパーティションのみをスキャンし、関係のないパーティションはスキップします。これにより、スキャンされるデータ量が削減され、クエリ速度が向上します。

        • インデックススキャンパフォーマンスの向上。インデックスがカバーする行数が多すぎると(例:5,000 万行以上)、インデックススキャンの効率が低下します。インデックスはパーティションレベルであり、各パーティションには独立したインデックスがあります。テーブルがパーティション化されていない場合、すべてのデータが単一のパーティションに格納されます。データ量が数千万行を超えると、インデックススキャン効率が低下します。テーブルをパーティション化することで、データが異なるシャードのパーティションに分散されます。これにより、各パーティションのインデックスに含まれる行数を数千万以内に制御でき、最適なスキャンパフォーマンスを維持できます。

        • BUILD 効率の向上。BUILD 操作はリアルタイムデータを既存データに変換します。このプロセスにはパーティションの作成、インデックスの構築、冗長データのクリーンアップが含まれます。新しいインデックスは BUILD 操作が完了した後にのみ有効になります。テーブルがパーティション化されていない場合、各 BUILD 操作でテーブル全体が処理されます。テーブルが大きくなるほど BUILD 操作に時間がかかり、新しいインデックスの有効化が遅れ、クエリパフォーマンスが低下します。テーブルがパーティション化されている場合、BUILD 操作はデータ変更のあるパーティションでのみ実行されるため、BUILD 時間が短縮されます。

      • LIFECYCLE 句と組み合わせてパーティションを使用し、データのライフサイクルを管理できます。

      • ストレージポリシー (storage_policy) と組み合わせてパーティションを使用し、ホットデータとコールドデータを階層化できます。

      データパーティションとライフサイクル管理

      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 関数を使用して、日時カラムを指定された日付形式に変換し、パーティション分割を行います。format パラメーターは年、月、日の形式(%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 タイムスタンプである必要があります。

      注意事項

      • カーネルバージョンが 3.2.1.0 よりも古いクラスターの場合、PARTITION BY を使用してパーティションを定義する際は、ライフサイクルLIFECYCLE n)を必ず定義する必要があります。定義しないとエラーが発生します。

      • カーネルバージョンが 3.2.1.0 以降のクラスターの場合、PARTITION BY を使用してパーティションを定義する際、ライフサイクル(LIFECYCLE n)は省略可能です。このパラメーターを省略した場合、システムはパーティションデータをクリーンアップしません。

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

      推奨事項

      • 日時型のフィールドをパーティションキーとして使用することを推奨します。

      • パーティションが大きすぎたり小さすぎたりすると、クエリおよび書き込みパフォーマンスが低下し、クラスターの安定性に影響を与える可能性があります。パーティションあたりの推奨行数およびパーティション戦略の検証方法については、「パーティションテーブルの診断」をご参照ください。

      • 過去のパーティションのデータを頻繁に更新しないでください。たとえば、毎日複数の過去のパーティションを頻繁に更新している場合は、パーティションキーが適切かどうかを再評価する必要があります。

      LIFECYCLE n

      LIFECYCLE 句を PARTITION BY と組み合わせて使用し、パーティションのライフサイクルを管理します。AnalyticDB for MySQL はパーティションキーの値に基づいてパーティションを降順にソートし、上位 n 個のパーティションを保持し、範囲外のパーティションを削除します。LIFECYCLE を使用してデータ保持期間を定義できます。

      • カーネルバージョンが 3.2.1.1 よりも古い場合、LIFECYCLE n各シャードが最大 n 個のパーティションを保持することを指定します。シャードレベルでパーティションのライフサイクルを管理する場合、データが不均等に分散されているか、データ量が極端に小さいと、保持されるパーティションの総数が n を超える可能性があります。

      • カーネルバージョンが 3.2.1.1 以降で、XUANWU エンジンを使用するテーブルの場合:アップグレード後に作成された新しいテーブルはテーブルレベルのライフサイクル管理を使用し、LIFECYCLE n各テーブルが最大 n 個のパーティションを保持することを指定します。アップグレード前に作成されたテーブルは引き続きシャードレベルのライフサイクル管理を使用し、LIFECYCLE n各シャードが最大 n 個のパーティションを保持することを指定します。

      • XUANWU_V2 エンジンを使用するテーブルは引き続きシャードレベルのライフサイクル管理を使用し、LIFECYCLE n各シャードが最大 n 個のパーティションを保持することを指定します。XUANWU_V2 エンジンはまだテーブルレベルのライフサイクル管理をサポートしていません。

      PARTITION BY VALUE (DATE_FORMAT(date, '%Y%m%d')) LIFECYCLE 30 句は、date カラムを yyyyMMdd 形式に変換してデータをパーティション分割し、最大 30 個のパーティションを保持します。たとえば、1 日目のデータがパーティション 20231201 に、2 日目のデータがパーティション 20231202 に書き込まれ、30 日目のデータがパーティション 20231230 に書き込まれるとします。31 日目のデータがパーティション 20231231 に書き込まれる際に、最も古いパーティション(20231201)が自動的に削除され、パーティション数が最大 30 個に維持されます。

      index_all

      すべてのカラムにインデックスを作成するかどうかを指定します。

      有効値

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

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

      storage_policy

      Enterprise Edition、Basic Edition、Data Lakehouse Edition クラスターおよび Data Warehouse Edition(エラスティックモード) クラスター(新規)では、ストレージポリシーを指定できます。異なるストレージポリシーは、読み取り/書き込みパフォーマンスとストレージコストのバランスが異なります。

      有効値

      • hot(デフォルト):ホットストレージ。このポリシーは、すべてのテーブルパーティションを SSD に格納します。最高のパフォーマンスを提供しますが、ストレージコストが最も高くなります。

      • cold:コールドストレージ。このポリシーは、すべてのテーブルパーティションを Object Storage Service (OSS) に格納します。ホットストレージと比較して、パフォーマンスは低くなりますが、ストレージコストが最も低くなります。

      • mixed:階層化ストレージ。このポリシーは、頻繁にアクセスされるデータ(ホットデータ)を SSD に、あまりアクセスされないデータ(コールドデータ)を OSS に格納することで、ストレージコストとクエリパフォーマンスのバランスを取ります。mixed ポリシーを使用するには、PARTITION BY 句でパーティションを定義し、hot_partition_count パラメーターでホットパーティションの数を指定する必要があります。パーティションが定義されていない場合、mixed ポリシーは効果がなく、システムはすべてのデータを 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 パラメーターは、カラム指向ストレージにおける各データブロックに含まれる行数を指定します。この値を調整すると、1 回の I/O 操作で読み取られる行数が変化し、クエリパターンによってパフォーマンスへの影響が異なります。たとえば、ポイントクエリの場合、大きな BLOCK_SIZE は効率を低下させる可能性があります。なぜなら、少数の行を取得する場合でもシステムはブロック全体を読み取る必要があるためです。このような場合、BLOCK_SIZE を小さく設定することでパフォーマンスを向上させることができます。

      デフォルト値:

      • 4096:レプリケートされたテーブルのデフォルト値です。

      • 8192:エラスティックモードの新規クラスターエディションおよび 32 コア未満のコンピュートコアを持つスタンドアロンエディションのデフォルト値です。

      • 32760:その他のすべての場合のデフォルト値です。このデフォルト値が使用されている場合、SHOW CREATE TABLE 文には BLOCK_SIZE 設定が表示されません。

      重要

      カラム指向ストレージの原理に不慣れな場合は、BLOCK_SIZE の値を変更しないでください。

      Engine

      AnalyticDB for MySQL の既存データ分析に使用される内部テーブルのストレージエンジンを指定します。

      • カーネルバージョンが 3.2.2.0 よりも古い場合、値は XUANWU です。テーブル作成時に ENGINE を明示的に指定しない場合のデフォルト値です。

        重要

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

      • カーネルバージョンが 3.2.2.0 以降の場合、有効値は次のとおりです。

        • 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 の値を変更することもできます。

      CTAS

      CREATE TABLE AS query_expr 文は、SELECT クエリの結果セットを使用してテーブルを作成および設定します。詳細な使用方法については、「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 の各列が composite primary key を構成します。distribution keycustomer_idpartition keylogin_timelifecycle は 30 に設定されます。

      パーティションは partition key login_time(例:20231202、20231201)の降順でソートされます。システムは、キー値が最大の上位 30 個のパーティションのみを保持します。31 番目のパーティションにデータが書き込まれると、システムは自動的にキー値が最小のパーティションを削除します。

      たとえば、1 日目に login_time が 20231201 のデータが書き込まれ、2 日目に 20231202 のデータが書き込まれる、といった具合に処理が進むと仮定します。31 日目に login_time が 20231231 のデータが書き込まれると、システムは自動的に最も古いデータを持つパーティション('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 '顧客情報テーブル';                   

      非パーティションテーブル

      デフォルト動作:プライマリキーを分散キーとして使用

      テーブルに primary key を定義するものの distribution key を指定しない場合、AnalyticDB for MySQL はデフォルトで primary keydistribution key として使用します。

      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)
      );

      SHOW CREATE TABLE 文を実行して結果を確認します。出力には、primary key 列である order_id および order_datedistribution key としても使用されていることが示されます。

      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)

      デフォルト動作:自動追加されるプライマリキーおよび分散キー

      primary keydistribution key を指定せずにテーブルを作成すると、AnalyticDB for MySQL は自動的に __adb_auto_id__ という名前の column を追加し、これを primary key および distribution key の両方として使用します。

      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 '注文日'
      );

      SHOW CREATE TABLE 文を実行して結果を確認します。出力には、AnalyticDB for MySQL が auto-increment column である __adb_auto_id__ を追加し、これを primary key および distribution key の両方として設定していることが示されます。

      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 という名前のテーブルを作成します。supplier_id 列は auto-increment column です。distribution keysupplier_id であり、データは supplier_id の値をハッシュ化することでシャーディングされます。

      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);

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

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

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

      short_feature(型:array<smallint>)および float_feature(型:array<float>)を、ディメンションが 4 のベクトルカラムとして定義します。

      short_feature カラムにベクトルインデックス short_feature_index を、float_feature カラムにベクトルインデックス 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 句を使用して、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 配列インデックス」をご参照ください。

      よくある質問

      列の属性と制約

      自動インクリメント列の値は 1 から始まりますか?また、一意ですか?

      自動インクリメント列の値は連続していませんし、1 から始まりません。ただし、一意であることは保証されています。

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

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

      データは、分散キーの値のハッシュに基づいてシャード間で分散されます。各シャード内では、さらにパーティションキーの値に基づいてパーティションに分割されます。次の図はこのプロセスを示しています。

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

      • パーティションテーブルを作成する際、分散キーの指定はオプションです。分散キーを指定しない場合、AnalyticDB for MySQL はプライマリキーを分散キーとして使用します。プライマリキーが指定されていない場合は、システムが自動的に __adb_auto_id__ という名前の列を作成し、これを分散キーとプライマリキーの両方として使用します。

      • レプリケートされたテーブルを作成する場合は、分散キーを指定する必要はありません。ただし、各ストレージノードにデータの完全なコピーを格納することを示すために、DISTRIBUTED BY BROADCAST を指定する必要があります。

      クラスター仕様を変更すると、シャード数は変わりますか?

      いいえ。クラスター仕様を変更しても、シャード数は変わりません。

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

      テーブルのパーティション情報をクエリするには、次の SQL ステートメントを実行します。

      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 ジョブが完了するのをお待ちください。その後、パーティション情報を確認できます。

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

      特定のパーティションからデータをクエリするには、フィルター条件 WHERE <partition key name> = '<partition key value>' を使用します。SELECT * FROM table PARTITION(202304) のような類似の使用方法はサポートされていません。

      以下は、特定のパーティション内のデータをクエリする方法の例です。

      order_date 列でパーティション化された orders_demo という名前のパーティションテーブルが作成されています。以下はサンプルの CREATE TABLE ステートメントです。

      CREATE TABLE orders_demo (
        order_id BIGINT NOT NULL COMMENT 'Order ID',
        customer_id INT NOT NULL COMMENT 'Customer ID',
        order_status VARCHAR(1) NOT NULL COMMENT 'Order status',
        total_price DECIMAL(15, 2) NOT NULL COMMENT 'Order amount',
        order_date DATE NOT NULL COMMENT 'Order date',
        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 TABLE orders_demo;
      BUILD ジョブは、テーブルが特定の条件を満たした場合に自動的にトリガーされます。この例では、以降の手順を容易にするために手動で BUILD ジョブを実行しています。詳細については、「automatic BUILD」をご参照ください。

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

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

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

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

      パーティションキーが DATETIME 型の場合、WHERE order_date >= "2023-10-01 00:00:00" and order_date < "2023-10-02 00:00:00" のように時間範囲を指定して、2023-10-01 のパーティション内のデータをクエリする必要があります。サンプルステートメントを以下に示します。

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

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

      いいえ。ただし、パーティションキーをフィルター条件として使用すると、システムが全テーブルではなく関連するパーティションのみをスキャンできるため、クエリパフォーマンスが大幅に向上します。

      パーティションキーのデータ型要件は何ですか?

      パーティションキーは、数値、日時、または数値を表す文字列型である必要があります。他のデータ型を使用すると、データ書き込みエラーが発生する可能性があります。

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

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

      いいえ。パーティションキーは、PARTITION BY VALUE(column)PARTITION BY VALUE(DATE_FORMAT(column,'format'))、または PARTITION BY VALUE(FROM_UNIXTIME(column,'format')) のいずれかの方法でのみ定義できます。他の関数を使用するとエラーが発生します。

      説明

      パーティションキーの定義方法の詳細については、「partition_options (Partition key and lifecycle)」をご参照ください。

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

      SHOW CREATE TABLE <table_name> ステートメントを実行して CREATE TABLE ステートメントを表示すると、パーティションテーブルのライフサイクルを確認できます。

      ライフサイクルを 30 日に設定しましたが、30 日以上前のデータをまだクエリできるのはなぜですか?

      この問題は、以下の理由で発生します。

      • パーティションの有効期限が切れたばかりで、システムがまだ削除していない場合。システムは有効期限切れのパーティションデータを即座に削除せず、テーブルの BUILD ジョブが完了した後にのみ削除します。

      • カーネルバージョン 3.2.1.1 より前のバージョンを実行しているクラスターで作成されたテーブルでは、LIFECYCLE はシャードごとに保持するパーティション数を定義します。シャード上の実際のパーティション数が指定された LIFECYCLE 値より少ない場合にこの問題が発生します。カーネルバージョン 3.2.1.1 以降を実行しているクラスターで作成されたテーブルでは、この問題は発生しません。

        例:

        • データ分布の不均等:データが日付でパーティション化されていると仮定します。シャード 1 には 20231201 から 20231230 までのパーティションが含まれ、シャード 2 には 20231202 から 20231231 までのパーティションが含まれている場合、両方のシャードには 30 個のパーティションがあり、これは LIFECYCLE 値 30 を超えていません。したがって、どちらのシャードからもパーティションは削除されず、20231201 から 20231231 までのデータをクエリできます。

        • 長期間にわたり新しいデータが書き込まれていない場合:データが日付でパーティション化されており、シャード 1 に 20231201202312022023120320231204 のパーティションが含まれていると仮定します。20231204 の後にテーブルに新しいパーティションデータが書き込まれない場合、シャード 1 には 4 つのパーティションしかありません。この数は LIFECYCLE 値 30 を超えていないため、パーティションは削除されません。20231231 の後でも、20231201 のデータを引き続きクエリできます。

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

      いいえ。システムはパーティションをリアルタイムで作成または削除しません。パーティションの有効期限が切れた後、テーブルの BUILD ジョブが完了した時点でシステムが削除します。

      インデックス

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

      SHOW CREATE TABLE ステートメントを実行して、CREATE TABLE ステートメントで定義されたクラスター化インデックスを確認します。

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

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

      INDEX(column1, column2) のような複合インデックスはサポートされていますか?

      いいえ。AnalyticDB for MySQL は複合インデックスをサポートしていません。インデックスには INDEX(column1) のように単一の列のみを含めることができます。

      列指向ストレージ

      CREATE TABLE 文における TABLE_PROPERTIES='{"format":"columnstore"}' とは何を意味しますか?

      TABLE_PROPERTIES='{"format":"columnstore"}' 句は、ENGINE 内のデータに対してカラム指向ストレージフォーマットを指定する固定値です。テーブル作成時にこのプロパティを手動で指定する必要はありません。

      テーブルで、一部のパーティションにロウ指向ストレージを使用し、他のパーティションにカラム指向ストレージを使用することはできますか?

      いいえ。

      その他

      テーブル作成後、ALTER TABLE 文で変更可能なパラメーターはどれですか?

      ALTER TABLE 文を使用して、以下のパラメーターを変更できます。

      • table_namecolumn_namecolumn_type、および COMMENT

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

      • 列のデフォルト値

      • NOT NULL から NULL への変更

      • INDEX インデックスの追加および削除

      • パーティション関数の日付形式

      • ライフサイクル

      • ストレージポリシー

      構文の詳細については、「ALTER TABLE」をご参照ください。

      テーブル作成後は、その他のパラメーターを変更できません。

      クラスター内で作成可能なテーブルの最大数はいくつですか?

      クラスターエディションによって、AnalyticDB for MySQL クラスターに作成できるテーブルの最大数が決まります:

      • Enterprise Edition80000/(Number of shards/Number of reserved resource nodes/3)Number of shards/Number of reserved resource nodes/3 の値は切り上げられます。内部テーブル数の上限を増やすには、reserved resource nodes を追加できます。

      • Basic Edition80000/(Number of shards/Number of reserved resource nodes)(Number of shards/Number of reserved resource nodes) の値は切り上げられます。内部テーブル数の上限を増やすには、reserved resource nodes を追加できます。

      • Enterprise Edition、Basic Edition、Data Lakehouse Edition、および Data Warehouse Edition (Elastic Mode) クラスターは、最大 500,000 の外部テーブルをサポートします。

      • Data Lakehouse Edition:内部テーブル数の上限は [80000/(Number of shards/Number of reserved storage resource groups)]*2 です。予約済みストレージリソースグループは 24 ACU です。たとえば、クラスターに予約済みストレージリソースが 48 ACU ある場合、グループ数は 2 になります。内部テーブル数の上限を増やすには、reserved storage resources をスケールアップできます。

      • Data Warehouse Edition (Elastic Mode):内部テーブル数の上限は [80000/(Number of shards/Number of EIUs)]*2 です。Number of shards/Number of EIUs の値は切り上げられます。EIU はエラスティック I/O ユニットを意味します。内部テーブル数の上限を増やすには、EIUs を追加できます。

      • Data Warehouse Edition (Reserved Mode)(ノードグループ数 1~20):内部テーブル数の上限は 80000/(Number of shards/Number of node groups) です。Number of shards/Number of node groups の値は切り上げられます。内部テーブル数の上限を増やすには、ノードグループを追加できます。

      説明

      シャード数をクエリするには、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 ステートメントでパーティションを定義していますが、ライフサイクルが指定されていません。

      以下の CREATE TABLE ステートメントはこのエラーを引き起こします。

      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;
      説明

      このエラーは、カーネルバージョン 3.2.1.0 より前のバージョンを実行しているクラスターでのみ発生します。

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

      原因: このエラーは、AnalyticDB for MySQL クラスターのパーティション数が 204,800 の制限を超えた場合に発生します。

      クラスター内のパーティション数を確認するには、次のステートメントを実行してください。

      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]

      原因: プライマリキーには、分散キーとパーティションキーの両方を含める必要があります。

      誤った SQL ステートメントの例 1:

      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__ のみ)にはパーティションキーが含まれないため、操作は失敗します。

      誤った SQL ステートメントの例 2:

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

      解決方法: PRIMARY KEY 定義にパーティションキーを追加してください。

      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 などのデータソースからデータをインポートする方法については、「データインポート」をご参照ください。