clickhouse mergetree引擎单次insert必生成至少一个part，因设计如此无法绕过；高频小写导致part爆炸，需控制单次1万～10万行、每秒≤1次、同分区写入，并调优合并参数与应用层背压。
为什么单次INSERT会生成一个Part文件
ClickHouse 的 MergeTree 引擎不是按行追加，而是每次执行 INSERT 语句（无论写入1行还是10万行），都会在磁盘上生成至少一个独立的 part 目录。这个行为是引擎设计决定的，无法绕过。高频小批量写入（比如每条Kafka消息触发一次 INSERT）等于在1秒内生成上百个 part，而后台 Merge 线程根本来不及合并——最终触发 Too many parts (300) 报错。
必须控制单次写入的数据量和频率
关键不是“能不能写快”，而是“要不要让ClickHouse自己扛住高频小写”。答案是否定的。生产环境应严格遵循：
- 单次
INSERT行数建议在10,000～100,000之间；太小 → part爆炸；太大 → 内存溢出或超时 - 写入频率控制在每秒 ≤ 1 次大批量写入；不要用多线程并发往同一张表发
INSERT - 写入数据尽量落在**同一个分区键值内**（例如同一天、同一商户ID）；跨分区写入会为每个分区各生成part，加速碎片累积
- 如果用
DataX，把batchSize调到50000，同时把channel并发数压到10以内（默认50极易踩坑）
服务端参数不能只调大parts_to_throw_insert
盲目把 parts_to_throw_insert 从300改成600，只是延迟报错时间，并不能解决合并跟不上写入的根本问题。反而可能让查询变慢（更多part意味着更多文件要打开扫描）。真正该调的组合是：
-
parts_to_delay_insert设为400，让系统在接近阈值时主动sleep降速 -
max_parts_in_total可适当提高（如200000），但必须配合监控system.parts -
background_pool_size加到16或24（默认16），提升Merge线程并行度 - 禁用
async_insert = 1用于生产写入——它只是把报错延后，不减少part生成
Buffer表不是万能解药，慎用
Buffer 表看起来很美：建一张缓冲表，业务无感写入，它自动攒批刷到目标表。但实际踩坑点很多：
- 缓冲区满之前，数据只存在内存里，进程崩溃就丢数据（无持久化）
- 缓冲策略中的
num_layers（如默认16）和min_time（如10秒）若没对齐业务节奏，可能造成延迟毛刺 - 一旦目标表写入卡住（如磁盘慢、part太多），Buffer表会持续积压，最终OOM
- 它无法解决上游分区倾斜问题（比如Kafka某个partition积压750万条），只是把问题往后挪
真正稳定的方案，是在应用层做双缓冲+背压反馈——当检测到 system.parts 中某张表的 active_parts > 200 时，主动限流上游消费速度。
