同一条 SQL 上午 800ms下午 18 秒。执行计划文本几乎没变团队开始改写子查询、加 Hint、调并行度。真正的变化是当天一个渠道占了 78% 数据单个 Scan 实例和 Join 分区拖住了整个查询。SQL 决定逻辑数据分布和运行时资源决定成本。EXPLAIN 只能告诉你准备怎么跑Query Profile 才能证明时间花在哪里。四种慢查询看起来一样处理完全不同Profile 证据真正根因有效动作无效动作ScanRows 远高于预期分区裁剪或谓词下推失败修正数据类型、分区条件、索引盲目加并行度同算子 Max 远高于 AvgTablet 或 Key 倾斜改分桶、拆热点、改 Join 分布只看总耗时ExchangeBytes 异常大Shuffle 或中间结果放大调整 Join 顺序、预过滤、Colocate增加 Scan 线程WaitForDependency 高Build、Sort、Agg 或资源排队找上游阻塞和内存瓶颈重写 SELECT 列表Query Profile 官方文档 建议在 MergedProfile 比较同一算子的 Min、Avg、Max。Max 显著大于 Avg或 Min 为 0 而 Max 很大是倾斜的直接信号。诊断顺序只有四步确认是不是同一条件保存 SQL、Session 变量、数据时间范围、并发、缓存冷热和集群负载。只说昨天快今天慢没有可比性。用 EXPLAIN 查计划错误EXPLAINVERBOSESELECTchannel,SUM(amount)FROMfact_orderWHEREpay_date2026-08-27GROUPBYchannel;检查分区数量、Scan 谓词、估算行数、Join 顺序和 Exchange。统计信息过期会让 CBO 用错误基数做出合理但错误的选择。用 Profile 查运行事实SETenable_profiletrue;-- 执行目标 SQLSHOWQUERY PROFILE;沿最慢 Fragment 向下追先找耗时最大的 Operator再比较各 PipelineTask。不要从几百个 Counter 中随机挑一个最大值。用单变量实验验证强制分区条件、更新统计信息、隔离并发或对比 Shuffle Hint每次只改一个变量。耗时下降但关键 Counter 没变化不能证明动作命中根因。一个可复现的倾斜实验向测试表写入 1000 万行其中channel app占 80%其他渠道均分。按channel分桶后执行聚合再改用高基数user_id分桶进行同量对比。应记录每个 Scan 实例的 InputRows聚合实例 RowsProducedMax/Avg 执行时间ExchangeBytes峰值内存与 Spill。如果热点分桶让单实例承担大部分数据增加 BE 只能增加空闲节点。数据没有被重新切开并行度不会凭空出现。EXPLAIN 与 Profile 的关系像地图和行车记录仪工具最适合证明不能证明EXPLAIN优化器选择、Fragment、分区、Join 分布实际行数、资源竞争、长尾实例Query Profile实际耗时、行数、内存、等待和网络为什么优化器当初做出该估算系统监控BE CPU、磁盘、内存、队列哪个算子制造了压力三者必须按 Query ID 和时间窗口关联。只看系统 CPU 高无法知道是目标 SQL 还是 Compaction只看 Profile也无法判断同一时间其他工作负载抢走了多少资源。源码阅读只追 Counter 的产生位置Doris4.0.8中源码最有价值的用法是从异常 Profile Counter 反查对应 OperatorScan 的读取与过滤、Exchange 的发送接收、Hash Join 的 Build/Probe、Dependency 的等待。这样能确认 Counter 包含什么、不包含什么。不要从 Coordinator 开始通读整个执行引擎。没有现场 Counter 作为入口源码只会变成另一篇概念综述。调优完成的标准不是更快一次在相同数据和并发下连续采样 P50、P95、P99同时确认 ScanRows、ExchangeBytes、Max/Avg 差距和峰值内存均按预期变化。还要在导入与 Compaction 同时运行时复测。一条 SQL 的文字从未改变不代表它执行的是同一份数据、同一种分布和同一组资源。官方资料Query ProfileProduct ConceptsMPP Architecture