AnalyticDB:ALTER TABLE

テーブル名の変更

構文

ALTER TABLE db_name.table_name RENAME new_table_name

例

customer テーブルの名前を new_customer に変更します。

ALTER TABLE customer RENAME new_customer;

テーブルコメントの変更

構文

ALTER TABLE db_name.table_name COMMENT 'comment'

例

customer テーブルのコメントを '顧客テーブル' に変更します。

ALTER TABLE customer COMMENT 'Customer table';;

列の追加

構文

ALTER TABLE db_name.table_name ADD [COLUMN] 
 {column_name column_type [DEFAULT {constant|CURRENT_TIMESTAMP}|AUTO_INCREMENT] [NULL|NOT NULL] [COMMENT 'comment']
 | (column column_type [DEFAULT {constant|CURRENT_TIMESTAMP}|AUTO_INCREMENT] [NULL|NOT NULL] [COMMENT 'comment'],...)}

注意

プライマリキー列は追加できません。

例

• customer テーブルに VARCHAR 型の province という名前の列を追加します。

ALTER TABLE adb_demo.customer ADD COLUMN province VARCHAR COMMENT 'Province';

• customer テーブルに 2 つの列を追加します。BOOLEAN 型の vip という名前の列と、VARCHAR 型の tags という名前の列です。

ALTER TABLE adb_demo.customer ADD COLUMN (vip BOOLEAN COMMENT 'VIP かどうか',tags VARCHAR DEFAULT 'None' COMMENT 'タグ');

列の削除

構文

ALTER TABLE db_name.table_name DROP [COLUMN] column_name

注意事項

プライマリキー列は削除できません。

例

customer テーブルから VARCHAR 型の province 列を削除します。

ALTER TABLE adb_demo.customer DROP COLUMN province;

列名の変更

構文

ALTER TABLE db_name.table_name RENAME COLUMN column_name to  new_column_name

注意

プライマリキー列の名前は変更できません。

例

customer テーブルの city_name 列の名前を city に変更します。

ALTER TABLE customer RENAME COLUMN city_name to city;

列のデータ型の変更

構文

ALTER TABLE db_name.table_name MODIFY [COLUMN] column_name new_column_type

注意

• プライマリキー列のデータ型は変更できません。

• データ型の変更には、次の制限が適用されます。

  • データ型は、より広い値の範囲を持つ別のデータ型にのみ変更できます。

  • 整数データ型: TINYINT から BIGINT など、より小さい整数型をより大きい整数型に変更できます。BIGINT から TINYINT には変更できません。サポートされている整数型は、TINYINT、SMALLINT、INT、および BIGINT です。

  • 浮動小数点データ型: FLOAT を DOUBLE に変更できますが、DOUBLE を FLOAT に変更することはできません。

  • 整数データ型 (TINYINT、SMALLINT、INT、または BIGINT) を浮動小数点データ型 (FLOAT または DOUBLE) に変更できます。

  • DECIMAL 型の精度を上げることはできます。精度を下げることはできません。

  重要

  カーネルバージョンが 3.1.8.10 から 3.1.8.x、3.1.9.6 から 3.1.9.x、3.1.10.3 から 3.1.10.x、または 3.2.0.1 以降のクラスターのみが、整数データ型から浮動小数点データ型への変更と DECIMAL 型の精度の変更をサポートしています。

例

customer テーブルの age 列のデータ型を INT から BIGINT に変更します。

ALTER TABLE adb_demo.customer MODIFY COLUMN age BIGINT;

列のデフォルト値の変更

構文

ALTER TABLE db_name.table_name MODIFY [COLUMN] column_name column_type DEFAULT {constant | CURRENT_TIMESTAMP}

例

• customer テーブルの sex 列のデフォルト値を 0 に設定します。

ALTER TABLE adb_demo.customer MODIFY COLUMN sex INT NOT NULL DEFAULT 0;

• customer テーブルの login_time 列のデフォルト値を CURRENT_TIMESTAMP に設定します。

ALTER TABLE adb_demo.customer MODIFY COLUMN login_time TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP;

NULL 値の許可

構文

ALTER TABLE db_name.table_name MODIFY [COLUMN] column_name column_type {NULL}

注意

NOT NULL 制約を NULL にのみ変更できます。

例

customer テーブルの province 列が NULL 値を受け入れるようにします。

ALTER TABLE adb_demo.customer MODIFY COLUMN province VARCHAR NULL;

列コメントの変更

構文

ALTER TABLE db_name.table_name MODIFY [COLUMN] column_name column_type COMMENT 'new_comment'

例

customer テーブルの province 列のコメントを '顧客が所在する省' に変更します。

ALTER TABLE adb_demo.customer MODIFY COLUMN province VARCHAR COMMENT 'The province where the customer is located';

インデックスの追加

デフォルトでは、AnalyticDB for MySQL は XUANWU_V2 テーブル (INDEX_ALL='N') のフルカラムインデックスを作成しませんが、XUANWU テーブル (INDEX_ALL='Y') の場合は作成します。XUANWU_V2 または XUANWU テーブルを作成したときにフルカラムインデックスが作成されなかった場合は、列にインデックスを追加できます。

構文

ALTER TABLE db_name.table_name ADD {INDEX|KEY} [index_name] (column_name)

パラメーターの説明

column_name: 列の名前。列は単純なデータ型である必要があります。列が JSON データ型の場合は、「JSON インデックスの追加」をご参照ください。

例

customer テーブルの age 列にインデックスを追加します。

ALTER TABLE adb_demo.customer ADD KEY age_idx(age);

フルカラムインデックスの変更

AnalyticDB for MySQL の XUANWU_V2 テーブルでは、テーブル作成後にフルカラムインデックスを変更できます。これは、テーブルプロパティ INDEX_ALL を使用して設定されます。この操作は、JSON、フルテキスト、ベクトルインデックスなどの非通常のインデックスには影響しません。

前提条件

XUANWU_V2 テーブルは、メジャーエンジンバージョンが 3.2.3.7 以降、または 3.2.4.3 以降のクラスターにあります。

構文

ALTER TABLE db_name.table_name INDEX_ALL = {'Y'|'N'};

パラメーターの説明

INDEX_ALL: すべての列に通常のインデックスを作成するかどうかを指定します。有効な値:

• Y: フルカラムインデックスモード。 すべての列に通常のインデックスを作成します。

  テーブルプロパティを INDEX_ALL='N' から INDEX_ALL='Y' に変更すると、インデックスがないすべての列に通常のインデックスが作成されます。

• N: 非フルカラムインデックスモード。 プライマリキーにのみ通常のインデックスを作成します。他の列には通常のインデックスはありません。

  テーブルプロパティを INDEX_ALL='Y' から INDEX_ALL='N' に変更すると、プライマリキー列のインデックスを除き、すべての通常のインデックスが削除されます。

注意

• XUANWU テーブルの場合、フルカラムインデックス機能はテーブル作成時にのみ設定できます。フルカラムインデックスを無効にするには、インデックスを削除する文を実行してインデックスを手動で削除する必要があります。

• INDEX_ALL='Y' の場合、データ定義言語 (DDL) 文を実行して通常のインデックスを削除すると、プロパティが自動的に INDEX_ALL='Y' から INDEX_ALL='N'に変更されます。この操作は、ターゲットの通常のインデックスのみを削除し、他の通常のインデックスには影響しません。

• テーブルプロパティが INDEX_ALL='N' の場合、SHOW CREATE TABLE 文ではプロパティが INDEX_ALL='N' として明示的に表示されない場合があります。ただし、有効になるプロパティは依然として INDEX_ALL='N'です。

例

• customer テーブルに INDEX_ALL='Y' があると仮定します。次の文を実行して、テーブルプロパティを INDEX_ALL='N' に変更します。

  ALTER TABLE adb_demo.customer INDEX_ALL = 'N';

  文が実行されると、customer_name、city_name、sex などのすべての非プライマリキー列の通常のインデックスが削除されます。

• customer テーブルに INDEX_ALL='N' があり、customer_id、phone_num、login_time フィールドにすでにインデックスがあると仮定します。次の文を実行して、テーブルプロパティを INDEX_ALL='Y' に変更します。

  ALTER TABLE adb_demo.customer INDEX_ALL = 'Y';

  文が実行されると、customer_name、city_name、sex など、まだインデックスがない列に通常のインデックスが作成されます。

JSON インデックスの追加

ALTER TABLE db_name.table_name ADD {INDEX|KEY} [index_name] (column_name|column_name->'$.json_path')

CREATE TABLE json_test(
  id INT,
  vj JSON
)
DISTRIBUTED BY HASH(id);

INSERT INTO json_test VALUES(1,'{"a":1,"b":2}'),(2,'{"a":2,"b":3}'));

ALTER TABLE json_test ADD KEY age_idx(vj->'$.a');

ALTER TABLE db_name.table_name ADD {INDEX|KEY} [index_name] (column_name->'$[*]')

CREATE TABLE json_test(
  id INT,
  vj JSON
)
DISTRIBUTED BY HASH(id);

INSERT INTO json_test VALUES(1, '["CP-018673", 1, false]');

ALTER TABLE json_test ADD KEY index_vj(vj->'$[*]');

インデックスまたは JSON インデックスの削除

ALTER TABLE db_name.table_name DROP KEY index_name

クラスター化インデックスの追加

構文

ALTER TABLE db_name.table_name ADD CLUSTERED [INDEX|KEY] [index_name] (column_name1 [ASC|DESC], column_name2 [ASC|DESC])

注

• デフォルトでは、クラスター化インデックスは昇順 (ASC) でソートされ、昇順でソートするクエリに適しています。クエリが降順でソートする場合は、テーブルを作成するときにクラスター化インデックスを降順 (DESC) に設定します。

• テーブルにはクラスター化インデックスを 1 つしか含めることができません。すでに存在する場合、別のクラスター化インデックスを追加することはできません。

• クラスター化インデックスを追加した後、クラスター化インデックスを有効にするには、BUILD ジョブをトリガーして完了する必要があります。SHOW CREATE TABLE db_name.table_name; 文を実行して、クラスター化インデックスが有効になったかどうかを判断できます。

例

customer テーブルの customer_id 列にクラスター化インデックスを追加できます。

ALTER TABLE adb_demo.customer ADD CLUSTERED KEY (customer_id ASC);

クラスター化インデックスの削除

構文

ALTER TABLE db_name.table_name DROP CLUSTERED KEY index_name

パラメーターの説明

index_name: クラスター化インデックスの名前。SHOW CREATE TABLE db_name.table_name を実行してクラスター化インデックス名を見つけることができます。

例

customer テーブルから index という名前のクラスター化インデックスを削除します。

ALTER TABLE adb_demo.customer DROP CLUSTERED KEY index;

フルテキストインデックスの追加

前提条件

構文

ALTER TABLE db_name.table_name ADD FULLTEXT [INDEX|KEY] index_name (column_name) [index_option]

パラメーターの説明

• column_name: フルテキストインデックスを作成する列。列は VARCHAR 型である必要があります。

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

  • WITH ANALYZER analyzer_name: フルテキストインデックスに使用されるアナライザを指定します。AnalyticDB for MySQL でサポートされているアナライザの詳細については、「フルテキストインデックスのアナライザ」をご参照ください。

  • WITH DICT tbl_dict_name: フルテキストインデックスに使用されるカスタム辞書を指定します。AnalyticDB for MySQL でサポートされているカスタム辞書の詳細については、「フルテキストインデックスのカスタム辞書」をご参照ください。

注意

作成したフルテキストインデックスは、BUILDジョブが再トリガーされて完了した後にのみ有効になります。

例

customer テーブルの home_address 列にフルテキストインデックスを追加します。

ALTER TABLE adb_demo.customer ADD FULLTEXT INDEX fidx_k(home_address) WITH ANALYZER standard;

フルテキストインデックスの削除

構文

ALTER TABLE db_name.table_name DROP FULLTEXT INDEX index_name

パラメーターの説明

• column_name: フルテキストインデックスを作成する列の名前。列は VARCHAR 型である必要があります。

• index_option: フルテキストインデックスに使用するアナライザとカスタム辞書。このパラメーターはオプションです。

  • WITH ANALYZER analyzer_name: フルテキストインデックスに使用するアナライザを指定します。AnalyticDB for MySQL でサポートされているアナライザの詳細については、「フルテキストインデックスのアナライザ」をご参照ください。

  • WITH DICT tbl_dict_name: フルテキストインデックスに使用するカスタム辞書を指定します。AnalyticDB for MySQL でサポートされているカスタム辞書の詳細については、「フルテキストインデックスのカスタム辞書」をご参照ください。

例

customer テーブルからフルテキストインデックス fidx_k を削除します。

ALTER TABLE adb_demo.customer DROP FULLTEXT INDEX fidx_k;

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

ベクトルインデックスの追加

前提条件

V3.1.4.0 以降の AnalyticDB for MySQL クラスターが作成されていること。

構文

ALTER TABLE db_name.table_name ADD ANN [INDEX|KEY] [index_name] (column_name) [algorithm=HNSW_PQ ] [distancemeasure=SquaredL2]

パラメーターの説明

• index_name: インデックスの名前。インデックスの命名規則については、「Limits」トピックの「命名制限」セクションをご参照ください。

• column_name: ベクトル列の名前。列の型は array <float>、array <byte>、または array <smallint> である必要があります。

• algorithm: ベクトル距離の計算に使用されるアルゴリズム。値を HNSW_PQ に設定します。

• distancemeasure: ベクトル距離の計算に使用される数式。値を SquaredL2 に設定します。SquaredL2 の計算式: (x1 - y1)<sup>2</sup> + (x2 - y2)<sup>2</sup> + ...(xn - yn)<sup>2</sup>。

例

次の文を使用して作成された vector という名前のテーブルがあるとします。

CREATE TABLE vector (
  xid BIGINT not null,
  cid BIGINT not null,
  uid VARCHAR not null,
  vid VARCHAR not null,
  wid VARCHAR not null,
  float_feature array < FLOAT >(4),
  short_feature array < SMALLINT >(4),
  PRIMARY KEY (xid, cid, vid)
) DISTRIBUTED BY HASH(xid);

float_feature 列と short_feature 列にベクトルインデックスを作成します。

ALTER TABLE vector ADD ANN INDEX idx_float_feature(float_feature);
ALTER TABLE vector ADD ANN INDEX idx_short_feature(short_feature);

外部キーの追加

前提条件

AnalyticDB for MySQL クラスターは、カーネルバージョン 3.1.10 以降を実行している必要があります。

構文

ALTER TABLE db_name.table_name ADD [CONSTRAINT [symbol]] FOREIGN KEY (fk_column_name) REFERENCES db_name.pk_table_name (pk_column_name)

パラメーターの説明

• db_name.table_name: 外部キーを追加するテーブル。

• symbol: オプション。外部キー制約の名前。テーブル内で一意である必要があります。指定しない場合、Resolver は自動的にサフィックス _fk を外部キー列名に制約名として追加します。

• fk_column_name: 外部キー列を指定します。外部キー列は CREATE TABLE 文で定義する必要があります。

• 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 はデータ制約チェックを実行しません。プライマリテーブルのプライマリキーと詳細テーブルの外部キーの間のデータ制約関係を確保する必要があります。

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

例

次の文を使用して作成された item と store_sales の 2 つのテーブルがあるとします。

CREATE TABLE item
(
 i_item_sk BIGINT NOT NULL,
 i_current_price BIGINT,
 PRIMARY KEY(i_item_sk)
)
DISTRIBUTED BY HASH(i_item_sk);

CREATE TABLE store_sales
(
 ss_sale_id BIGINT,
 ss_store_sk BIGINT,
 ss_item_sk BIGINT NOT NULL,
 PRIMARY KEY(ss_sale_id)
);

store_sales テーブルに外部キー ss_item_sk を追加し、それを item テーブルの i_item_sk キーに関連付けます。

ALTER TABLE store_sales ADD CONSTRAINT ss_item_sk FOREIGN KEY (ss_item_sk) REFERENCES item (i_item_sk);

詳細については、「プライマリキーと外部キーの制約を使用して不要な結合を排除する」をご参照ください。

外部キーの削除

構文

ALTER TABLE db_name.table_name DROP FOREIGN KEY fk_symbol

例

ALTER TABLE store_returns DROP FOREIGN KEY sr_item_sk_fk;

パーティションのライフサイクルの変更

構文

ALTER TABLE db_name.table_name PARTITIONS N

注意

• カーネルバージョンが 3.2.4.1 以降のクラスターでは、LIFECYCLE パラメーター N を 0 に設定することで、パーティションのライフサイクル管理を削除できます。

• パーティションのライフサイクルを変更した後、新しいライフサイクルを有効にするには、BUILDタスクをトリガーして完了する必要があります。SHOW CREATE TABLE db_name.table_name; 文を実行して、新しいライフサイクルが有効になったかどうかを確認できます。

例 1

customer テーブルからライフサイクルを削除します。

ALTER TABLE customer PARTITIONS 0;

例 2

customer テーブルのライフサイクルを 30 から 40 に変更します。

ALTER TABLE customer PARTITIONS 40;

パーティションの削除

構文

ALTER TABLE db_name.table_name DROP PARTITION (partition_name,...)

注意

パーティションを削除すると、そのパーティション内のデータも削除され、回復できません。この操作を実行するときは注意してください。

例

• customer テーブルから 20241220 パーティションを削除します。

  ALTER TABLE adb_demo.customer DROP PARTITION (20241220);

• customer テーブルから 20241218 と 20241219 のパーティションを削除します。

  ALTER TABLE adb_demo.customer DROP PARTITION (20241218,20241219);

階層型ストレージポリシーの変更

前提条件

• クラスターは、Enterprise Edition、Basic Edition、Data Lakehouse Edition、または Data Warehouse Edition (Elastic mode) です。

• カーネルバージョン:

  • テーブルエンジンが XUANWU の場合、クラスターのカーネルバージョンに制限はありません。

  • テーブルエンジンが XUANWU_V2 の場合、クラスターのカーネルバージョンは次のいずれかの条件を満たす必要があります。

    • 3.2.2.15 以降。

    • 3.2.3.13 以降。

    • 3.2.4.9 以降。

    • 3.2.5.3 以降。

    説明

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

• テーブルエンジンが XUANWU_V2 の場合、クラスターでホットストレージとコールドストレージ間でデータを移動するためのスケジュールされたタスクを有効にする必要があります。

  • タスクが有効になっているか確認します: SHOW ADB_CONFIG KEY=SERVERLESS_DATA_STORAGE_CHANGE_SCHEDULE_ENABLE;。コマンドが FALSE を返す場合、タスクは無効になっているため、有効にする必要があります。エラーが返された場合、パラメーターは設定されておらず、デフォルト値は TRUE です。

  • タスクを有効にします: SET ADB_CONFIG SERVERLESS_DATA_STORAGE_CHANGE_SCHEDULE_ENABLE = true;。

構文

ALTER TABLE db_name.table_name STORAGE_POLICY= {'HOT'|'COLD'|'MIXED' hot_partition_count=N}

使用上の注意

ホットデータとコールドデータの階層型ストレージポリシーを変更した後、新しいポリシーは、テーブルの BUILD ジョブがトリガーされて完了した後にのみ有効になります。デフォルトでは、このジョブはバックグラウンドで定期的に自動実行されます。BUILD ジョブが完了する前に、information_schema.table_usage によって返されるホットパーティションの数が定義されたストレージポリシーと一致しないのは正常です。SHOW CREATE TABLE db_name.table_name; を実行して、新しいストレージポリシーが有効になったかどうかを確認できます。

例

• customer テーブルのストレージポリシーを COLD に変更します。

  ALTER TABLE customer storage_policy = 'COLD';

• customer テーブルのストレージポリシーを HOT に変更します。

  ALTER TABLE customer storage_policy = 'HOT';

• customer テーブルのストレージポリシーを MIXED に変更し、ホットパーティションの数を 10 に設定します。

  ALTER TABLE customer storage_policy = 'MIXED' hot_partition_count = 10;