避免变异
在 ClickHouse 中，变异 (mutations) 指的是修改或删除表中现有数据的操作——通常使用 ALTER TABLE ... DELETE 或 ALTER TABLE ... UPDATE。虽然这些语句看起来与标准的 SQL 操作类似，但它们在底层是完全不同的。
与就地修改行不同，ClickHouse 中的变异是异步后台进程，会重写受更改影响的整个 数据部分 (data parts)。这种方法是由于 ClickHouse 的列式、不可变存储模型所必需的，并且可能导致大量的 I/O 和资源使用。
当发出变异时，ClickHouse 会安排创建新的 变异数据部分 (mutated parts)，在新的数据部分准备好之前，原始数据部分保持不变。准备好后，变异的数据部分会原子性地替换原始数据部分。但是，由于该操作重写整个数据部分，即使是小的更改（例如更新单行）也可能导致大规模重写和过度的写入放大。
对于大型数据集，这可能会导致磁盘 I/O 的大幅增加并降低整个集群的性能。与合并不同，变异一旦提交就无法回滚，并且即使在服务器重启后也会继续执行，除非明确取消——请参阅 KILL MUTATION。
有关如何监控活动或排队的变异数量，请参阅以下 知识库文章。
变异是 完全排序的 (totally ordered)：它们适用于在变异发出之前插入的数据，而较新的数据不受影响。它们不会阻塞插入，但仍然可能与其他正在进行的查询重叠。在变异期间运行的 SELECT 查询可能会读取混合的变异和未变异数据部分，这可能导致执行期间数据视图不一致。ClickHouse 会并行处理每个数据部分上的变异，这可能会进一步加剧内存和 CPU 使用率，尤其是在涉及复杂的子查询（例如 x IN (SELECT ...)) 时。
作为规则，避免频繁或大规模的变异，尤其是在高吞吐量表上。相反，使用替代的表引擎，例如 ReplacingMergeTree 或 CollapsingMergeTree，这些引擎旨在在查询时或合并期间更有效地处理数据更正。如果变异是绝对必要的，请使用 system.mutations 表仔细监控它们，如果进程卡住或行为异常，请使用 KILL MUTATION。错误地使用变异可能导致性能下降、过度的存储消耗和潜在的服务不稳定——因此请谨慎并适度地应用它们。
对于删除数据，您还可以考虑 轻量级删除 (Lightweight deletes) 或通过 分区 (partitions) 管理数据，这些分区允许高效地 删除整个数据部分 (dropped efficiently)。
