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_planner=false;SETGLOBALnereids_timeout_second=120;逻辑很简单：
前置 SQL 一加上，数据终于顺畅地灌进去了。看着控制台亮起的绿灯，我毫无波澜，甚至有点想笑。
今日总结：永远不要高估新特性的泛用性，也永远不要低估第三方商业平台的离谱程度。在数据开发的泥潭里，最高端的坑，往往只需要最朴实无华的SET变量来填平。下班！
