AnalyticDB:ALTER TABLE

前提条件

XUANWU_V2 テーブルは、カーネルバージョンが 3.2.3.7 以降、または 3.2.4.3 以降のクラスター上に存在する必要があります。

クラスターのマイナーバージョンを表示および更新するには、AnalyticDB for MySQL コンソールにログインし、[Cluster Information] ページの [Configuration Information] セクションに移動してください。

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

使用上の注意：

• XUANWU テーブルの場合、全列インデックスはテーブル作成時にのみ設定できます。無効にするには、インデックスを個別に削除する必要があります。

• INDEX_ALL='Y' の場合にデータ定義言語 (DDL) 文を使用して通常のインデックスを削除すると、プロパティは自動的に INDEX_ALL='N' に変更されます。対象のインデックスのみが削除され、他のインデックスは影響を受けません。

• INDEX_ALL='N' の場合、SHOW CREATE TABLE ではこのプロパティが明示的に表示されないことがありますが、引き続き有効です。

例 1： customer の全列インデックスを無効にします (現在は INDEX_ALL='Y')。

ALTER TABLE adb_demo.customer INDEX_ALL = 'N';

実行後、customer_name、city_name、sex などのプライマリキー以外のカラムの通常のインデックスは削除されます。

例 2： customer の全列インデックスを有効にします (現在は INDEX_ALL='N' で、customer_id、phone_num、login_time に既存のインデックスがあります)。

ALTER TABLE adb_demo.customer INDEX_ALL = 'Y';

実行後、customer_name、city_name、sex など、まだインデックスがないすべてのカラムに通常のインデックスが作成されます。

使用上の注意

JSON インデックスの動作は、テーブルエンジンによって異なります：

• XUANWU_V2 テーブル (パーティション化されたテーブルとパーティション化されていないテーブル)：インデックスはすぐに有効になります。BUILD ジョブは必要ありません。

• パーティション化されていない XUANWU テーブル：インデックスは、BUILD ジョブが完了した後にのみ有効になります。

• パーティション化された XUANWU テーブル：手動で全テーブルの BUILD ジョブをトリガーする必要があります。インデックスは、BUILD ジョブが完了した後にのみ有効になります。

前提条件

AnalyticDB for MySQL クラスター V3.1.4.9 以降。最良の結果を得るには、V3.1.4.17 以降を推奨します。

マイナーバージョンの照会方法については、「AnalyticDB for MySQL クラスターのバージョンを照会する方法」をご参照ください。

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

例： standard アナライザーを使用して、home_address カラムにフルテキストインデックスを追加します。

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

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

前提条件

AnalyticDB for MySQL クラスター V3.1.4.0 以降。推奨されるマイナーバージョン：3.1.5.16、3.1.6.8、3.1.8.6 以降。

お使いのクラスターが推奨バージョンのいずれでもない場合は、ベクトル検索を使用する前に [CSTORE_PROJECT_PUSH_DOWN] と CSTORE_PPD_TOP_N_ENABLE を false に設定してください。マイナーバージョンを更新するには、テクニカルサポートにお問い合わせください。マイナーバージョンの照会方法については、「AnalyticDB for MySQL クラスターのバージョンを照会する方法」をご参照ください。

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

例： float_feature カラムと short_feature カラムにベクトルインデックスを作成します。

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

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 クラスター V3.1.10 以降。

マイナーバージョンを表示および更新するには、AnalyticDB for MySQL コンソールにログインし、[Cluster Information] ページの [Configuration Information] セクションに移動してください。

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

使用上の注意：

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

• 外部キーインデックスは複数のカラムにまたがることはできません (例：FOREIGN KEY (sr_item_sk, sr_ticket_number) はサポートされていません)。

• AnalyticDB for MySQL はデータ制約を強制しません。アプリケーションでプライマリキーと外部キーの間の制約関係を検証してください。

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

例： item テーブルを参照する外部キーを store_sales に追加します。

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

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

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

前提条件

• クラスターが Enterprise Edition、Basic Edition、Data Lakehouse Edition、または Data Warehouse Edition (Elastic モード) であること。

• カーネルバージョンの要件：

  • 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; を実行して、ポリシーが有効であることを確認してください。

例 1： ストレージポリシーを COLD に設定します。

ALTER TABLE customer storage_policy = 'COLD';

例 2： ストレージポリシーを HOT に設定します。

ALTER TABLE customer storage_policy = 'HOT';

例 3： ストレージポリシーを、ホットパーティション数が 10 の MIXED に設定します。

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