clickhouse不擅长更新和删除操作，更新操作很重，更新是重新创建一个分区，更新完后，太混之前的
ClickHouse提供了DELETE和UPDATE的能力，这类操作被称为Mutation查询，它可以看作ALTER语句的变种。虽然Mutation能最终实现修改和删除，但不能完全以通常意义上的UPDATE和DELETE来理解，我们必须清醒地认识到它的不同：首先，Mutation语句是一种“很重”的操作，更适用于批量数据的修改和删除；其次，它不支持事务，一旦语句被提交执行，就会立刻对现有数据产生影响，无法回滚；最后，Mutation语句的执行是一个异步的后台过程，语句被提交之后就会立即返回。所以这并不代表具体逻辑已经执行完毕，它的具体执行进度需要通过system.mutations系统表查询。注意数据的修改和删除操作是使用MergeTree家族引擎:
ALTER TABLE test_ud
DELETE WHERE id = ‘1’
Received exception from server (version 20.8.3):
Code: 48. DB::Exception: Received from localhost:9000. DB::Exception: Mutations are not supported by storage Log.
删除数据语法：
ALTER TABLE [db_name.]table_name DELETE WHERE filter_expr
示例：
CREATE TABLE test_ud
(
id String,
name String,
job String
)
ENGINE = MergeTree
ORDER BY id;
insert into test_ud values (1,‘zhangsan’,‘coder’) ;
insert into test_ud values (2,‘lisi’,‘coder’) ;
删除数据：
ALTER TABLE test_ud
DELETE
WHERE id = ‘1’
查询数据：
SELECT *
FROM test_ud
查看表存储数据的目录,我们发现表的目录下多出一个文件
修改数据语法，修改数据支持同时修改多个字段
ALTER TABLE [db_name.]table_name UPDATE column1 = expr1 [, …] WHERE filter_expr
ALTER TABLE test_ud
UPDATE name = ‘my’, job = ‘teacher’ WHERE id = ‘2’ ; --但是注意的时候一定指定where条否则会报错,这种语法的where条件也可以使用子查询 ;
查看mutation队列
那么，怎么查看数据是否更新完成了呢？
可以通过system.mutations表查看相关信息：
SELECT
database,
table,
command,
create_time,
is_done
FROM system.mutations
ORDER BY create_time DESC
LIMIT 10;
database: 库名
table: 表名
command: 更新/删除语句
create_time: mutation任务创建时间，系统按这个时间顺序处理数据变更
is_done: 是否完成，1为完成，0为未完成
通过以上信息，可以查看当前有哪些mutation已经完成，is_done为1即表示已经完成。
Mutation具体过程
首先，使用where条件找到需要修改的分区；
然后，重建每个分区，用新的分区替换旧的，分区一旦被替换，就不可回退；
对于每个分区，可以认为是原子性的；但对于整个mutation，如果涉及多个分区，则不是原子性的。
注意事项
更新功能不支持更新有关主键或分区键的列
更新操作没有原子性，即在更新过程中select结果很可能是一部分变了，一部分没变，从上边的具体过程就可以知道
更新是按提交的顺序执行的
更新一旦提交，不能撤销，即使重启clickhouse服务，也会继续按照system.mutations的顺序继续执行
已完成更新的条目不会立即删除，保留条目的数量由finished_mutations_to_keep存储引擎参数确定。超过数据量时旧的条目会被删除
更新可能会卡住，比如update intvalue='abc’这种类型错误的更新语句执行不过去，那么会一直卡在这里，此时，可以使用KILL MUTATION来取消，语法：
kill mutation where database=‘app’ and table=‘test’ // database、table是system.mutations表中的字段
使用建议
按照官方的说明，update/delete的使用场景是一次更新大量数据，也就是where条件筛选的结果应该是一大片数据。
举例：alter table test update status=1 where status=0 and day=‘2020-04-01’，一次更新一天的数据。
那么，能否一次只更新一条数据呢？例如：alter table test update pv=110 where id=100
当然也可以，但频繁的这种操作，可能会对服务造成压力。这很容易理解，如上文提到，更新的单位是分区，如果只更新一条数据，那么需要重建一个分区；如果更新100条数据，而这100条可能落在3个分区上，则需重建3个分区；相对来说一次更新一批数据的整体效率远高于一次更新一行。
对于频繁单条更新的这种场景，建议使用ReplacingMergeTree/CollapsingMergeTree引擎来变相解决。
