三种清理方式的区别
DROP TABLE 删除表定义与数据；TRUNCATE TABLE 保留表结构、只清空数据；DETACH 把表从服务下线但磁盘数据保留，需要时再 ATTACH 回来。清理历史数据时更推荐按分区删除，成本最低，也最容易预估影响范围。
为什么删完空间没降
删除类操作大多只是标记数据不可用或把文件挪走，真正的文件回收依赖后台合并与清理流程，所以磁盘占用不会立刻下降。DROP 与 TRUNCATE 都没有回收站，误删只能靠备份或另行保存的文件副本恢复。
基本信息
| DROP TABLE | [IF EXISTS] 删除表定义与数据，文件由后台异步清理 |
|---|---|
| TRUNCATE TABLE | 快速清空数据，表定义与结构保留 |
| DETACH / ATTACH | 下线与重新加载表，磁盘数据文件不动 |
| 分区级清理 | ALTER TABLE ... DROP PARTITION 只删指定分区 |
| 适用版本 | ClickHouse 各主流版本均支持 |
示例
示例
-- 清空数据但保留表结构
TRUNCATE TABLE staging.events;
-- 删表，建议带 IF EXISTS 避免脚本中断
DROP TABLE IF EXISTS staging.tmp_events;
-- 下线与重新加载：数据文件仍保留在磁盘
DETACH TABLE events;
ATTACH TABLE events;
-- 按分区删除历史数据，成本最低
ALTER TABLE events DROP PARTITION '202312';典型使用场景
- 清空测试数据：TRUNCATE 保留结构，脚本可以重复跑
- 清理临时表：跑批结束后 DROP 掉中间结果表
- 故障隔离：某张表引发查询异常时先 DETACH 下线，排完再 ATTACH
- 历史归档：按分区删除或导出后删除，避免全表重写
- 磁盘回收：删除后确认后台清理进度，再判断空间是否释放
操作与影响范围
| 操作 | 影响范围 | 能否恢复 |
|---|---|---|
| DROP TABLE | 表定义与数据一起删除 | 不可恢复，需要依赖备份 |
| TRUNCATE | 仅数据，结构保留 | 不可恢复 |
| DETACH | 仅从服务下线 | 可以 ATTACH 回来 |
| DROP PARTITION | 指定分区的数据 | 不可恢复，建议先归档 |
删除历史数据优先按分区删除；DETACH 之后表目录仍在磁盘上，误删时可以在同结构表上把数据文件恢复挂载回来。
DROP 与 TRUNCATE 都没有回收站，执行前确认库表名与备份状态；对分布式表执行删除只影响本地元数据，远端集群上的表需要逐节点处理。