同一条 SQL 上午 800ms，下午 18 秒。执行计划文本几乎没变，团队开始改写子查询、加 Hint、调并行度。真正的变化是当天一个渠道占了 78% 数据，单个 Scan 实例和 Join 分区拖住了整个查询。
SQL 决定逻辑，数据分布和运行时资源决定成本。EXPLAIN 只能告诉你准备怎么跑，Query Profile 才能证明时间花在哪里。
四种慢查询看起来一样，处理完全不同
| Profile 证据 | 真正根因 | 有效动作 | 无效动作 |
|---|---|---|---|
| ScanRows 远高于预期 | 分区裁剪或谓词下推失败 | 修正数据类型、分区条件、索引 | 盲目加并行度 |
| 同算子 Max 远高于 Avg | Tablet 或 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_date='2026-08-27'GROUPBYchannel;检查分区数量、Scan 谓词、估算行数、Join 顺序和 Exchange。统计信息过期会让 CBO 用错误基数做出合理但错误的选择。
用 Profile 查运行事实
SETenable_profile=true;-- 执行目标 SQLSHOWQUERY PROFILE;沿最慢 Fragment 向下追，先找耗时最大的 Operator，再比较各 PipelineTask。不要从几百个 Counter 中随机挑一个最大值。
用单变量实验验证
强制分区条件、更新统计信息、隔离并发或对比 Shuffle Hint，每次只改一个变量。耗时下降但关键 Counter 没变化，不能证明动作命中根因。
一个可复现的倾斜实验
向测试表写入 1000 万行，其中channel = app占 80%，其他渠道均分。按channel分桶后执行聚合，再改用高基数user_id分桶进行同量对比。
应记录：
- 每个 Scan 实例的 InputRows；
- 聚合实例 RowsProduced；
- Max/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 反查对应 Operator：Scan 的读取与过滤、Exchange 的发送接收、Hash Join 的 Build/Probe、Dependency 的等待。这样能确认 Counter 包含什么、不包含什么。
不要从 Coordinator 开始通读整个执行引擎。没有现场 Counter 作为入口，源码只会变成另一篇概念综述。
调优完成的标准不是更快一次
在相同数据和并发下连续采样 P50、P95、P99；同时确认 ScanRows、ExchangeBytes、Max/Avg 差距和峰值内存均按预期变化。还要在导入与 Compaction 同时运行时复测。
一条 SQL 的文字从未改变，不代表它执行的是同一份数据、同一种分布和同一组资源。
官方资料
- Query Profile
- Product Concepts
- MPP Architecture
