20260630被“聪明”的优化器和“努力”的BI平台混合双打的一天今天原本应该是个行云流水般发版上线的日子结果硬生生被两个卧龙凤雏逼成了一部排坑血泪史。完美的开局诡异的报错事情的起因很简单我要把一张将近 150 个字段的大宽表快照塞进 Doris 2.X 里。建表语句堪称艺术分区、分桶、各种组合键映射得明明白白。本以为点下执行就能去泡杯咖啡结果观远 BI 平台直接给我甩了一个大逼兜errorMsg: {error:回写数据失败, errCode 2, detailMessage Nereids cost too much time ( 31s 30s)}看到这个报错我人都麻了。Nereids这不是 Doris 2.X 引以为傲的全新查询优化器吗怎么写个数据还能超时痛批 Nereids杀鸡非要用牛刀顺藤摸瓜排查下去发现这个新版优化器在处理INSERT语句时简直是“脱裤子放屁——多此一举”。对于这种纯写入的大宽表本质上就是把数据搬进对应的物理路径里毫无复杂的 Join 或者聚合逻辑。结果 Nereids 非要在那里吭哧瘪肚地跑几十秒的解析和代价计算CBO算着算着把自己算超时了直接原地自尽。说真的新的优化器在复杂查询上可能确实有点东西但对于单纯的INSERT语句默认就应该直接 Bypass 回退到老版本优化器。插个数据你优化个什么劲呢简直是帮倒忙。观远 BI纯搞笑的自研驱动如果说 Nereids 是过于“聪明”那观远这个 BI 平台就是真的让我绷不住了。为什么 Nereids 会解析到吐血因为观远在往 Doris 写数据的时候居然是用极其古老的传统方式硬生生拼接了几千上万个 Values 的超级长 SQL 怼进去的Doris 官方最推荐、性能最高、闭着眼睛都能用的数据导入方式是什么是Stream Load。这已经是所有现代 OLAP 数据库生态的常识了。结果这平台不支持标准的 Stream Load 就算了居然还去费劲巴拉地“自研”了一套底层驱动。好家伙自研的结果就是回归原始社会用拼长 SQL 的方式把下游数据库的解析器给活活撑死。这波操作属实是又菜又爱玩纯搞笑来着。最终结局简单粗暴才是真理折腾到最后面对这种局面优雅的代码已经解决不了问题了。我在数据流的前置 SQL里直接加上了两句“法术封印”SETGLOBALenable_nereids_plannerfalse;SETGLOBALnereids_timeout_second120;逻辑很简单前置 SQL 一加上数据终于顺畅地灌进去了。看着控制台亮起的绿灯我毫无波澜甚至有点想笑。今日总结永远不要高估新特性的泛用性也永远不要低估第三方商业平台的离谱程度。在数据开发的泥潭里最高端的坑往往只需要最朴实无华的SET变量来填平。下班