system.merges 是什么
system.merges 实时展示正在进行的 part 合并任务：涉及的表、已耗时、进度、参与合并的 part 数量与内存占用。导入高峰期观察它可判断合并是否成为瓶颈，也能确认后台合并线程是否在正常工作。配套还有 system.mutations 看变更任务、system.parts 看合并后的结果，三者结合才能看清写入链路的完整状态。
基本信息
| 关键列 | database、table、elapsed、progress、num_parts、memory_usage、rows |
|---|---|
| 相关设置 | background_pool_size 控制后台合并线程数 |
| 辅助表 | system.mutations 看变更，system.parts 看结果 |
| 所属系统 | ClickHouse |
典型使用场景
- 写入高峰观察：确认合并速度是否跟得上导入速度
- 排查卡顿：合并长时间不推进时定位是磁盘还是资源问题
- 容量判断：合并过程中的临时空间占用高于静态估算
- 参数调整：根据并发合并数量判断是否需要调整后台线程数
- 数据核对：合并完成后用 system.parts 确认 part 数量与分布
查看合并与 part
查看合并与 part
SELECT database, table, round(elapsed, 1) AS sec, -- 已耗时（秒）
round(progress, 2) AS pct, num_parts, rows -- 进度与参与 part 数
FROM system.merges
ORDER BY elapsed DESC;
SELECT table, count() AS parts, sum(rows) AS rows -- 当前生效的 part 分布
FROM system.parts WHERE active GROUP BY table ORDER BY parts DESC;输出列读法
| 列 | 含义 | 读法 |
|---|---|---|
| elapsed | 已耗时 | 长时间不推进说明受阻 |
| progress | 完成比例 | 长期停在低比例要排查 |
| num_parts | 参与合并的 part 数 | 数量多说明碎片化明显 |
| memory_usage | 合并占用内存 | 会与查询内存互相挤占 |
| rows | 涉及行数 | 估算合并耗时的关键输入 |
合并是后台自然行为，长期没有合并任务通常说明写入量很小或者 part 已经足够大，不必过度解读。
调大 background_pool_size 会同时增加 CPU 与 IO 占用，业务查询高峰期要谨慎，宁可让合并稍微落后也不要拖慢查询。
合并卡住常与磁盘空间不足或某个超大 part 有关，结合 system.parts 与磁盘用量一起看比只盯 system.merges 更快定位。
单次能合并的 part 总大小受上限类设置约束，导入大批量数据时若看到 part 长期偏多，先确认这个上限与磁盘余量，再决定是否调整后台线程数。