ALTER
ほとんどのALTER TABLEクエリはテーブルの設定やデータを変更します:
ほとんどのALTER TABLEクエリは、*MergeTreeテーブル、Mergeおよび分散テーブルでのみサポートされています。
これらのALTERステートメントはビューを操作します：
- ALTER TABLE ... MODIFY QUERY — Materialized View構造を変更します。
- ALTER LIVE VIEW — Live Viewを更新します。
これらのALTERステートメントは、ロールベースのアクセス制御に関連するエンティティを修正します：
ALTER TABLE ... MODIFY COMMENTステートメントは、テーブルに対しコメントを追加、修正、または削除します。これは、以前に設定されていたかどうかに関係なく行われます。
ALTER NAMED COLLECTIONステートメントはNamed Collectionsを修正します。
変異（Mutations）
テーブルデータを操作することを意図したALTERクエリは、「変異」と呼ばれるメカニズムで実装されています。代表的なものに、ALTER TABLE ... DELETEやALTER TABLE ... UPDATEがあります。これらはMergeTreeテーブルのマージに似た非同期のバックグラウンドプロセスで、新しい「変化した」パーツのバージョンを生成します。
*MergeTreeテーブルでは、変異はデータ全体のパーツを書き換えることで実行されます。アトミシティはなく、パーツは変異された部分が準備ができ次第、入れ替えられ、変異中に開始されたSELECTクエリは既に変異されたパーツからのデータと、まだ変異されていないパーツからのデータの両方を参照します。
変異はその作成順に完全に順序付けられ、その順で各パーツに適用されます。また、変異はINSERT INTOクエリと部分的に順序付けられます：変異が提出される前にテーブルに挿入されたデータは変異され、後に挿入されたデータは変異されません。なお、変異はインサートを一切ブロックしません。
変異クエリは、変異エントリが追加されるとすぐに（レプリケートされたテーブルの場合はZooKeeper、非レプリケートされたテーブルの場合はファイルシステムに）応答を返します。変異自体はシステムのプロファイル設定を使用して非同期で実行されます。変異の進行状況を追跡するためには、system.mutationsテーブルを使用できます。正常に提出された変異は、ClickHouseサーバーが再起動されても実行を続けます。変異が一度提出されると巻き戻す方法はありませんが、何らかの理由で変異が詰まった場合は、KILL MUTATIONクエリでキャンセルできます。
終了した変異のエントリはすぐに削除されることはなく、保存されるエントリ数はfinished_mutations_to_keepストレージエンジンパラメータで決定されます。古い変異エントリは削除されます。
ALTERクエリの同期性（Synchronicity）
非レプリケートテーブルでは、すべてのALTERクエリは同期的に実行されます。レプリケートされたテーブルでは、クエリは適切なアクションに対する指示をZooKeeperに追加するだけで、そのアクション自体はできるだけ早く実行されます。ただし、クエリはこれらのアクションがすべてのレプリカで完了するのを待つことができます。
変異を作成するALTERクエリ（例：UPDATE、DELETE、MATERIALIZE INDEX、MATERIALIZE PROJECTION、MATERIALIZE COLUMN、APPLY DELETED MASK、CLEAR STATISTIC、MATERIALIZE STATISTICを含むがこれに限定されない）の同期性は、mutations_sync設定で定義されます。
メタデータのみを修正するその他のALTERクエリについては、alter_sync設定を使用して待機を設定できます。
非アクティブなレプリカがすべてのALTERクエリを実行するのを待機する時間（秒）を指定するには、replication_wait_for_inactive_replica_timeout設定を使用できます。
すべてのALTERクエリで、alter_sync = 2かつreplication_wait_for_inactive_replica_timeout設定で指定された時間を超えて非アクティブなレプリカがある場合、例外UNFINISHEDがスローされます。