每次 Stream Load 都成功每批只有几十 KBCPU 和磁盘也没有立刻打满。几小时后导入突然报-235业务以为遇到了随机故障。它不是突然发生的。每个成功小批都在给同一批 Tablet 增加版本Compaction 还债速度长期低于造债速度拒写只是最后一道保护。Doris 最怕的不是写得多而是把每一小撮数据都当成一笔独立事务。一分钟一万行和一秒一次并不是同一种负载固定每分钟写入 60 万行写法每分钟事务数主要成本典型结果每秒 100 次每次 100 行6000FE 事务、Rowset、版本、发布Version 快速累积每秒 1 次每次 1 万行60批次延迟与客户端缓存存储路径明显更健康Group Commit 合并小写入由服务端窗口决定等待窗口、WAL 或同步可见客户端保持小写服务端减少事务总行数相同版本生产速度可以相差两个数量级。扩容磁盘不能消除事务固定成本。复现实验固定表结构、数据量和持续时间只改变每批行数、每秒事务数以及是否启用 Group Commit持续记录热点 Tablet 的 VersionCount 与 Compaction Score。-235 前面的完整因果链高频小批 → 每批独立事务 → 每个受影响 Tablet 产生新 Rowset 与 Version → 查询需要合并更多读取路径 → Compaction 选择并重写 Rowset → 新版本产生速度长期高于合并速度 → VersionCount 触及保护上限 → 后续导入被 -235 拒绝数据导入 FAQ 将-235定义为对应 Tablet 版本数超过上限常见原因就是导入频率高于 BE Compaction 速度。它不是 Segment 过多的-238两者不能混调。先找到哪块 Tablet 在欠债止血前先做只读检查SHOWTABLETSFROMtarget_table;SHOWTABLETtablet_id;继续执行SHOW TABLET返回的 ProcPath重点比较各副本的VersionCount。如果只有少数 Tablet 高先查分桶热点和数据倾斜如果全表同步上涨优先查导入频率和 Compaction 能力。同时在对应 BE 查看Compaction Score 是否持续上升Cumulative/Base Compaction 是否执行或报错磁盘空间、I/O、CPU 和内存是否成为限制导入批次、并发数和每批涉及的分区数量。单看平均 Score 会隐藏一块即将拒写的热点 Tablet。Group Commit 优秀在服务端合并事务Group Commit 官方文档 描述的核心不是加速单批而是让多个并发小写入共享一笔事务。相同label和txnId是写入被合并的直接证据。SETgroup_commitasync_mode;INSERTINTOevent_logVALUES(...);INSERTINTOevent_logVALUES(...);sync_mode等到合并事务可见后返回async_mode写入 WAL 后可先返回PREPARE可见性稍后发生。追求最低客户端延迟时不能把收到响应误判成 SQL 已经可查。Group Commit 也有明确边界Stream Load 2PC、自定义 Label、部分列更新和显式事务可能绕过或回退普通路径严格依赖提交顺序的 Unique Key 表还需要 Sequence。止血不是调大上限处理顺序应该是降低或暂停问题表的小批写入让 VersionCount 是否下降成为第一项验证。将客户端攒批或在支持条件下启用 Group Commit。检查 Compaction 是否被磁盘、内存、线程或错误卡住。若仅单个 Tablet 热修正 Bucket Key 或分区策略。在灰度表重放同样负载要求版本增速长期低于消化速度。直接提高max_tablet_version_num只会推迟拒写并让查询承担更多 Rowset 合并。直接增加 Compaction 线程可能与导入和查询争夺同一组 CPU、磁盘和内存。源码只看版本保护与合并入口在 Doris4.0.8中源码阅读围绕三处Tablet 元数据维护版本、写入发布前检查版本数量、Compaction 调度按 Score 选择 Tablet。再向下追 Rowset 选择策略确认为什么某些尺寸差异过大的 Rowset 暂时不会被合并。源码不能替代现场证据。只有把报错 Tablet、VersionCount、Compaction Score、任务日志和导入频率串起来才能证明是版本债而不是磁盘故障或副本异常。-235不是故障起点而是 Doris 在版本债彻底失控前替你踩下的刹车。官方资料Group CommitData CompactionData Operation FAQCompaction Principles