ClickHouse 小 Part 堆积复盘从写入批次和 Merge 队列找证据ClickHouse 小 Part 堆积通常是写入粒度、Merge 资源和查询压力共同作用。复盘先按表、分区和时间查看系统表不用一个 Parts 数量直接给参数定罪。先看 Parts 的增长方式按表和分区查看system.parts再结合system.merges与写入请求的批次分布。短时间出现大量小 Part往往提示上游在频繁提交Merge 持续排队则需要同时检查磁盘、CPU、可用后台线程和查询竞争。不要仅凭 Parts 数量就认定某个参数“错误”。复盘时保留三个问题哪些表、分区和时间段出现了异常增长Merge 是否在运行还是被资源和队列限制上游批次、重试或分区策略在同一窗口发生了什么变化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 排队、写入失败和磁盘队列的联合告警。阈值应来自自身历史基线而不是通用“危险数”。告警触发后先收集系统表快照和上游写入速率再判断是否限流、扩容或修改写入策略。这样下一次定位会有数据而不依赖记忆。