ALTER TABLE 查询都会修改表设置或数据：
大多数
ALTER TABLE 查询仅适用于 *MergeTree、Merge 和 Distributed 表。ALTER 语句用于操作视图：
| 语句 | 描述 |
|---|---|
| ALTER TABLE … MODIFY QUERY | 修改 materialized view 的结构。 |
ALTER 语句用于修改与基于角色的访问控制相关的实体：
| 语句 | 描述 |
|---|---|
| ALTER TABLE … MODIFY COMMENT | 为表添加、修改或删除注释，无论之前是否设置过。 |
| ALTER NAMED COLLECTION | 修改 Named Collections。 |
变更
ALTER 查询，是通过一种称为“变更”的机制实现的，最典型的就是 ALTER TABLE … DELETE 和 ALTER TABLE … UPDATE。它们是异步后台进程，类似于 MergeTree 表中的合并，用于生成新的“mutated”版本的 parts。
对于 *MergeTree 表，变更是通过重写整个数据分区片段来执行的。
它不具备原子性——变更后的 parts 一旦准备就绪，就会立即替换原来的 parts；而在变更执行期间开始的 SELECT 查询，既会看到已经变更过的 parts 中的数据，也会看到尚未变更的 parts 中的数据。
变更按照创建顺序完全有序，并按该顺序应用到每个 part。变更与 INSERT INTO 查询之间也存在部分顺序关系：在变更提交之前插入到表中的数据会被变更，而在此之后插入的数据则不会被变更。请注意，变更不会以任何方式阻塞插入。
变更查询在变更条目添加完成后会立即返回 (对于复制表，会添加到 ZooKeeper；对于非复制表，则会添加到文件系统) 。变更本身会使用系统 profile 设置异步执行。要跟踪变更的进度，可以使用 system.mutations 表。成功提交的变更即使在 ClickHouse 服务器重启后也会继续执行。变更一旦提交，就无法回滚；但如果由于某种原因卡住了，可以使用 KILL MUTATION 查询将其取消。
已完成变更的条目不会立即删除 (保留条目的数量由存储引擎参数 finished_mutations_to_keep 决定) 。较早的变更条目会被删除。
ALTER 查询的同步性
ALTER 查询都会同步执行。对于复制表，查询只会将相应操作的指令添加到 ZooKeeper 中，而这些操作本身会尽快执行。不过，查询也可以等待，直到所有副本都完成这些操作。
对于会创建变更的 ALTER 查询 (例如但不限于 UPDATE、DELETE、MATERIALIZE INDEX、MATERIALIZE PROJECTION、MATERIALIZE COLUMN、APPLY DELETED MASK、APPLY PATCHES、CLEAR STATISTIC、MATERIALIZE STATISTIC) ，其同步方式由 mutations_sync 设置决定。
对于其他仅修改元数据的 ALTER 查询，可以使用 alter_sync 设置来配置等待行为。
你可以使用 replication_wait_for_inactive_replica_timeout 设置，指定等待非活动副本执行完所有 ALTER 查询的时长 (以秒为单位) 。
对于所有
ALTER 查询，如果 alter_sync = 2，且某些副本处于非活动状态的时间超过 replication_wait_for_inactive_replica_timeout 设置中指定的时长，则会抛出 UNFINISHED 异常。