DDL 変更のルールとベストプラクティス - PolarDB - Alibaba Cloud ドキュメントセンター

検索ビューを持つソーステーブルに対してデータ定義言語 (DDL) 操作を実行すると、同期リンクに影響が及ぶ可能性があります。このトピックでは、さまざまな DDL 操作の影響について説明し、必要に応じてビューを再構築するためのベストプラクティスを解説します。

DDL 変更がソーステーブルに与える影響

次の表は、さまざまな DDL 操作が検索ビューの同期リンクに与える影響について説明したものです。

変更タイプ	特定の操作	同期ステータス	説明
列の変更	列の削除	正常	削除された列の値は、既存のドキュメントに保持されます。増分データの場合、対応するフィールドの値は `null` になります。
	列の追加	正常	新しい列は自動的には同期されません。検索ビューに追加するには、「検索ビューを変更するためのベストプラクティス」をご参照ください。
	列の型の変更	型に依存	`INT` を `TINYINT` に変更するなど、型互換の変更の場合、増分データ同期は正常に継続されます。型非互換の変更の場合、検索ビューは利用できなくなり、再構築する必要があります。
	列名の変更	中断	検索ビューは、作成時の列名を使用します。列名を変更すると、検索ビューは名前が変更されたソーステーブルの列を見つけられなくなります。検索ビューを再構築する必要があります。
	その他 (列の並べ替え、デフォルト値の変更、コメントの変更、VARCHAR の長さの拡張、文字セットの変更、自動増分プロパティの変更、NULL 制約の変更など)	正常	これらの操作は、検索ビューの同期に影響を与えません。
インデックスの変更	セカンダリインデックスの追加、削除、または変更	正常	セカンダリインデックスへの変更は、同期に影響を与えません。
インデックスの変更	主キーインデックスの削除または変更	中断	検索ビューは、データ同期のためにソーステーブルのプライマリキーに依存しています。プライマリキーを変更した場合は、検索ビューを再構築する必要があります。
テーブルの変更	`TRUNCATE TABLE`	中断	検索ビューは `TRUNCATE` 操作を検出できません。テーブルデータをクリアして変更を同期するには、代わりに `DELETE FROM` を使用してください。
テーブルの変更	その他 (`OPTIMIZE TABLE`、`ROW_FORMAT` の変更、`KEY_BLOCK_SIZE` の変更、統計の更新、テーブルの文字セットの変更、テーブルのコメントの変更など)	正常	これらの操作は、検索ビューの同期に影響を与えません。
パーティションテーブルの変更	パーティションテーブルへの変換、パーティションの追加、パーティションのマージ、再パーティション化、パーティションの分析、パーティションのチェック、パーティションの最適化、パーティションの再構築、非パーティション化テーブルへの変換、ローカルインデックスの使用など	正常	これらの操作は、検索ビューの同期に影響を与えません。
	`DROP PARTITION`、`DROP TABLESPACE`、`TRUNCATE PARTITION`	中断	検索ビューはこれらの操作を検出できません。データを削除して変更を同期するには、代わりに `DELETE FROM` を使用してください。
	`EXCHANGE PARTITION`、`REPAIR PARTITION`、`IMPORT TABLESPACE`	中断	検索ビューは、パーティション内の直接的なデータ置換や修復を検出できません。他のパーティションのデータは影響を受けません。これらの操作を実行した後は、検索ビューを再構築してください。

検索ビューを変更するためのベストプラクティス

新しいフィールドの追加など、検索ビューの同期構造を変更するには、新しいインデックスと新しいビューを作成して再構築します。新しい検索ビューが完全に同期され、検証された後、アプリケーションのクエリトラフィックを新しいインデックスに切り替えることができます。

説明

既存の検索ビューを再構築せずにオンラインで変更することは、現在サポートされていません。

例：shop.user テーブルに新しい列を追加し、その検索ビューを再構築します。既存の検索ビューが shop.user テーブル (列 id, name, phone, gmt_create を含む) を user_v1 という名前のインデックスに同期しているとします。オンラインクエリを中断せずに membership_level 列を追加するには、次の手順を実行します。

新しいインデックスの作成：PolarSearch ノード上で、新しい membership_level フィールドをマッピングに含む user_v2 という名前の新しいインデックスを作成します。

PUT user_v2
{
  "mappings": {
    "properties": {
      "id":               { "type": "keyword" },
      "name":             { "type": "text", "fields": { "keyword": { "type": "keyword" } } },
      "phone":            { "type": "keyword" },
      "gmt_create":       { "type": "date" },
      "membership_level": { "type": "integer" }
    }
  }
}

ソーステーブルの変更：ソースの PolarDB for MySQL インスタンスで、user テーブルに新しい列を追加します。
```
ALTER TABLE shop.user ADD COLUMN membership_level TINYINT NOT NULL DEFAULT 0 COMMENT 'Membership level';
```
新しい検索ビューの作成：shop.user テーブルから user_v2 インデックスにデータを同期するための新しい検索ビューを作成します。
```
CREATE SEARCH VIEW user_v2 AS SELECT id, name, phone, gmt_create, membership_level FROM shop.user;
```
検証と切り替え：SHOW SEARCH VIEW STATUS を使用して、新しい検索ビューのステータスを確認します。同期遅延が 0～1 秒に低下したら、新しいインデックスのデータを検証します。確認後、アプリケーションのクエリトラフィックを新しい user_v2 インデックスに切り替えます。
古いリソースのクリーンアップ：新しい検索ビューが安定していることを確認した後、古い検索ビューと user_v1 インデックスを削除します。
```
DROP SEARCH VIEW user_v1;
```