ClickHouse 小 Part 堆积复盘：从写入批次和 Merge 队列找证据

ClickHouse 小 Part 堆积复盘：从写入批次和 Merge 队列找证据

ClickHouse 小 Part 堆积通常是写入粒度、Merge 资源和查询压力共同作用。复盘先按表、分区和时间查看系统表，不用一个 Parts 数量直接给参数定罪。

先看 Parts 的增长方式

按表和分区查看system.parts，再结合system.merges与写入请求的批次分布。短时间出现大量小 Part，往往提示上游在频繁提交；Merge 持续排队则需要同时检查磁盘、CPU、可用后台线程和查询竞争。不要仅凭 Parts 数量就认定某个参数“错误”。

复盘时保留三个问题

1. 哪些表、分区和时间段出现了异常增长？
2. Merge 是否在运行，还是被资源和队列限制？
3. 上游批次、重试或分区策略在同一窗口发生了什么变化？

SELECT database, table, partition, count() AS active_parts FROM system.parts WHERE active GROUP BY database, table, partition ORDER BY active_parts DESC LIMIT 20;

调整要从可回退的小动作开始

攒批大小与等待时间需要由业务时效和数据分布决定，不能照搬固定数值。先在一条写入链路上调整，观察 Parts 增长、Merge 进度、写入延迟和查询尾延迟；如果变差，回退并保留对比窗口。Buffer 表或异步写入也要评估进程重启、积压和可见性语义。

长效防线

给高频写入表建立 Parts、Merge 排队、写入失败和磁盘队列的联合告警。阈值应来自自身历史基线，而不是通用“危险数”。告警触发后先收集系统表快照和上游写入速率，再判断是否限流、扩容或修改写入策略。这样下一次定位会有数据，而不依赖记忆。