ClickHouse执行DROP COLUMN后磁盘空间未回收，需额外操作吗？

核心原因：Part存储格式与Mutation处理逻辑 #

• Wide/Compact格式的差异影响：
  若表采用Compact格式（默认是Wide，仅当建表指定format_version = 1或显式设置compact时启用），所有列数据会被打包在同一个.bin文件中。这种场景下DROP COLUMN无法直接删除单个列的独立文件，仅会标记该列不再被读取，实际数据仍保留在原part文件内，只有当该part被合并重写时，才会真正剔除被删列的数据。而Wide格式下每个列有独立的.bin和.mrk2文件，DROP COLUMN应该能直接删除对应列的文件，即时释放空间。
• Mutation的延迟清理机制：
  即便使用Wide格式，Mutation执行成功后旧part文件也不会立刻被删除——ClickHouse会默认保留这些文件24小时（由merge_tree.remove_detached_part_after_seconds参数控制，默认值86400秒），用于故障恢复。你可以检查/var/lib/clickhouse/data/<database>/<table>/detached目录，确认是否存在被标记待删除的part文件。

无需执行OPTIMIZE TABLE ... FINAL的替代方案 #

• 等待自动合并：MergeTree会在后台自动触发part合并，当包含被删列的旧parts被合并为新parts时，新parts不会包含已删除的列，旧parts会被自动清理，空间随之释放。这个过程是异步的，具体速度取决于集群的合并策略参数（如merge_tree.max_bytes_to_merge_at_max_space_in_pool）。
• 手动触发轻量合并（可选）：若想加快空间回收进程，可执行OPTIMIZE TABLE my_table（不带FINAL），它会触发后台合并任务，但不会强制合并所有parts，相比FINAL操作的资源开销低很多。注意：频繁手动合并可能影响集群性能。
• 手动清理detached目录（谨慎操作）：若确认旧parts已无恢复需求（如Mutation完成超过24小时），可手动删除detached目录下的对应文件，再执行ALTER TABLE my_table DROP DETACHED PART '<part_name>'让ClickHouse确认文件已删除。此操作不可逆，务必确认无风险后再执行。

总结 #

• Compact格式下必须等待part合并重写才能释放空间；Wide格式下大概率是旧parts仍在保留期内。
• 优先等待自动合并，非紧急情况不建议执行OPTIMIZE TABLE ... FINAL，避免过高的性能开销。

内容的提问来源于stack exchange，提问作者today