Lightweight Delete：删除标记和物理删除的区别

← 上一篇 Mutation：ALTER UPDATE/DELETE 为什么很重

做的事：真实对比两种删除方式，同样删1/3数据

代码-- 方式1：Lightweight Delete（ClickHouse 22.8+） DELETE FROM demo.ldel WHERE k < 1000000; -- 方式2：真正的mutation ALTER TABLE demo.mdel DELETE WHERE k < 1000000 SETTINGS mutations_sync=1;

验证：Lightweight Delete之后，part的行数元数据真实完全没变

实测 · 本机执行输出（DELETE FROM，lightweight delete）

删除前 system.parts：
  all_1_1_0   776094 行
  all_2_2_0  1111953 行
  all_3_3_0  1111953 行

DELETE FROM demo.ldel WHERE k < 1000000;   -- 真实耗时 0.058 秒

删除后 system.parts：
  all_1_1_0_4   776094 行   ← 真实行数一个都没少！
  all_2_2_0_4  1111953 行   ← 同样没变
  all_3_3_0_4  1111953 行   ← 同样没变

但 SELECT count() FROM demo.ldel; 真实返回 2000000（正确，1M已被逻辑删除）

Lightweight Delete的真实机制是给每个part悄悄加一个隐藏的_row_exists掩码列，把要删除的行标记为"不存在"，而不是真的把它们从part文件里抹掉——所以part的物理行数元数据rows完全没有变化，只是查询引擎在读取时会自动过滤掉被标记的行，让SELECT count()这类查询看到正确的逻辑结果（2000000）。

验证：ALTER TABLE DELETE之后，part真实变小了

实测 · 本机执行输出（ALTER TABLE DELETE，真正的mutation）

ALTER TABLE demo.mdel DELETE WHERE k < 1000000 SETTINGS mutations_sync=1;
→ 真实耗时 0.070 秒（这次同步等mutation真正完成）

删除后 system.parts：
  all_1_1_0_4  111953 行  ← 真实物理行数变少了
  all_2_2_0_4  776094 行  ← 真实物理行数变少了
  all_3_3_0_4 1111953 行  （这个part本身不含k<1000000的行，未受影响）

三个part真实剩余总行数 = 111953+776094+1111953 = 2000000，跟lightweight delete的逻辑结果一致

两种删除方式最终从SELECT的角度看结果一样，但物理层面真实完全不同：ALTER TABLE DELETE是一次真正的mutation，会把涉及的part完整重读、跳过命中WHERE条件的行、重新写一份只包含剩余行的新part——磁盘上被删的数据真的不占地方了；DELETE FROM（lightweight delete）只是打一个掩码，原来的数据依然真实躺在磁盘上，本文测试完成后哪怕逻辑上已经"删掉"了100万行，这100万行对应的.bin文件字节数其实丝毫未减。这也是为什么两者的耗时在小数据量下差不多（0.058s vs 0.070s，打标记和小范围重写在这个数据规模下都很快）——lightweight delete真实的优势在大数据量场景下才会拉开明显差距：它不需要立即读写整个part就能完成"删除"这个动作，真实的物理空间回收会等到这些part下一次因为正常后台merge而被重写时顺带发生，把重活分摊到了未来某次反正要做的merge里，而不是像ALTER DELETE那样立刻付出一次完整的part重写代价。

分步演示：从打掩码到真正的物理删除

每一步都是本文上面用真实两种DELETE方式跑出来的原始结果。

打掩码 vs 真实物理重写，两种删除的真实区别

这一步新验证的方式

本文用到的工具

本机 ClickHouse 26.9.4（单节点），真实对比 DELETE FROM（lightweight）与 ALTER TABLE DELETE（mutation）
真实的 system.parts rows列，证明物理数据是否真的缩小

下一篇 · CLICKHOUSE 内部原理 30

TTL：数据过期后到底什么时候被清理