背景：
clickhouse中一张数据表中一天有7000w数据，采用delete删除命令删除一周数据，sql已经执行成功，短时间内查询原表数据仍然存在，没有被删除，过了一会之后，在查询数据删除成功。
sql提交成功：
短时间内【40s】查询数据仍然存在
经过查阅资料得知，clickhouse提供了delete和update的能力，这类操作称为mutation查询，可以看作alter语句的变种。虽然mutation能最终实现修改和删除，但不能完全以通常意义上的update和delete来理解，我们必须认识到它的不同：
- mutation语句是一种“很重”的操作，更适用于批量数据的修改和删除；
- 它不支持事务，一旦语句被提交执行，就会立刻对现有数据产生影响，无法回滚；
- mutation语句的执行是一个异步的后台过程，语句被提交之后就会立即返回。
由于一般测试的数据很少，delete操作给人的感觉和常用的oltp数据库无异。但是我们心中应该要明白这是一个异步的后台执行动作。语句提交成功这并不代表具体逻辑已经执行完毕，它的具体执行进度需要通过system.mutations系统表查询。
delete语句的语法:
alter table [db_name.]table_name delete where filter_expr
数据删除的范围由where查询子句决定，删除操作是这样实现的：
在执行了delete操作之后数据目录发生了一些变化。【/chbase/data/default/test_table】每一个原有的数据目录都额外增加了一个同名目录，并且在末尾处增加了_【数字】的后缀。此外，目录下还多了一个名为mutation_【数字】.txt的文件，查看文件的内容如下所示：
# cat mutation_6.txt
format version: 1
create time: 2022-02-16 13:33:27 commands: delete where id = \'1\'
mutation_6.txt是一个日志文件，完整地记录了这次delete操作的执行语句和时间，而文件名的后缀_6与新增目录的后缀对应。那么后缀的数字从何而来呢？system.mutations系统表：
select database,table,mutation_id,block_numbers.number as num,is_done
from system.mutations综上，整个mutation操作的逻辑就比较清晰了。在每clickhouse执行一条alter delete语句，都会在mutations系统表中生成一条对应的执行计划，当is_done等于1时表示执行完毕。同时，在数据表的根目录下，会以mutation_id为名生成与之对应的日志文件用于记录相关信息。而数据删除的过程是以数据表的每个分区目录为单位，将所有目录重写为新的目录，新目录的命名规则是在原有名称上加上system.mutations.block_numbers.number。数据在重写的过程中会将需要删除的数据去掉。旧的数据目录并不会立即删除，而是会被标记成非激活状态（active为0）。等到mergetree引擎的下一次合并动作触发时，这些非激活目录才会被真正从物理意义上删除。