ClickHouse提供了Delete和Update的能力，这类操作被称为Mutation（突变）查询，它可以看做Alter 的一种。

虽然可以实现修改和删除，但是和一般的OLTP数据库不一样，Mutation语句是一种很“重”的操作，而且不支持事务。

“重”的原因主要是每次修改或者删除都会导致放弃目标数据的原有分区，重建新分区。所以尽量做批量的变更，不要进行频繁小数据的操作。

ALTER TABLE … UPDATE 语句

ALTER TABLE [db.]table UPDATE column1 = expr1 [, ...] WHERE filter_expr

ALTER TABLE … DELETE 语句

ALTER TABLE [db.]table [ON CLUSTER cluster] DELETE WHERE filter_expr

ALTER TABLE 的前缀使这个语法与其他大多数支持SQL的系统不同。它的目的是表明，与OLTP数据库中的类似查询不同，这是一个繁重的操作，不是为频繁使用而设计。

Mutations 突变

用来操作表数据的ALTER查询是通过一种叫做“突变”的机制来实现的，最明显的是ALTER TABLE … DELETE和ALTER TABLE … UPDATE。它们是异步的后台进程，类似于MergeTree表的合并，产生新的“突变”版本的部件。

对于 *MergeTree 表，通过重写整个数据部分来执行突变。没有原子性——一旦突变的部件准备好，部件就会被替换，并且在突变期间开始执行的 SELECT 查询将看到来自已经突变的部件的数据，以及来自尚未突变的部件的数据。

突变完全按照它们的产生顺序排列，并按此顺序应用于每个部分。突变还与“INSERT INTO”查询进行部分排序:在提交突变之前插入表中的数据将被突变，而在此之后插入的数据将不会被突变。注意，突变不会以任何方式阻止插入。

突变查询在添加突变条目后立即返回(对于复制表到ZooKeeper，对于非复制表到文件系统)。突变本身使用系统配置文件设置异步执行。要跟踪突变的进程，可以使用system.mutations 表。成功提交的变异将继续执行，即使ClickHouse服务器重新启动。没有办法回滚突变一旦提交，但如果突变卡住了，它可以取消与KILL MUTATION 查询。

完成突变的条目不会立即删除(保留条目的数量由 finished_mutations_to_keep 存储引擎参数决定)。删除旧的突变条目。

ALTER 查询的同步性

对于非复制表，所有的 ALTER 查询都是同步执行的。对于复制表，查询只是向“ZooKeeper”添加相应动作的指令，动作本身会尽快执行。但是，查询可以等待所有副本上的这些操作完成。

对于所有的“ALTER”查询，您可以使用alter_sync设置等待。

通过[replication_wait_for_inactive_replica_timeout](/docs/zh/operations/settings/settings#replication-wait-for-inactive-replica-timeout]设置，可以指定不活动的副本执行所有 ALTER 查询的等待时间(以秒为单位)。

!!! info "备注"