Apache Doris执行计划分析核心技术解析：3个维度掌握查询性能调优密码

🔍 问题引入：当SQL遇上"隐形的墙"

你是否曾遇到这样的情况：一条看似简单的SQL查询，在数据量增长后突然变得缓慢？或者明明添加了索引，查询效率却没有明显提升？这些问题的背后，往往隐藏着执行计划的"隐形决策"。执行计划分析正是揭开这个黑箱的关键技术，它能帮助我们理解查询引擎如何处理数据，找到性能瓶颈的根源。在Apache Doris中，执行计划不仅是优化器的"作战地图"，更是开发者进行查询性能调优的"透视镜"。你知道如何通过执行计划判断一个JOIN操作是否选择了最优算法吗？

📊 核心概念：执行计划的"数据流水线"模型

执行计划的本质：数据加工厂的生产蓝图

执行计划本质上是查询优化器为SQL语句生成的"数据加工流水线"。如果把SQL查询比作一份生产订单，那么执行计划就是详细的车间布局图和工序流程图。每个算子就像一个生产工位，数据从源头（扫描算子）进入流水线，经过一系列转换（过滤、连接、聚合等），最终输出成品（查询结果）。

图1：执行计划的"数据流水线"模型示意图

执行计划的生成过程

Apache Doris的执行计划生成分为三个阶段：

1. 语法解析：将SQL转换为抽象语法树（AST）
2. 逻辑优化：基于关系代数规则进行等价变换
3. 物理优化：结合统计信息选择最优执行策略

这个过程类似于建筑设计：先绘制概念图纸（逻辑计划），再确定具体施工方案（物理计划）。你觉得在哪个阶段引入统计信息对执行计划质量影响最大？

💡 实践指南：执行计划分析的"三板斧"

基础命令：EXPLAIN的进阶用法

除了基础的EXPLAIN SELECT ...语法，Doris还提供了两个高级命令：

-- 1. 显示执行计划的详细属性
EXPLAIN VERBOSE SELECT count(*) FROM sales WHERE dt = '2023-01-01';

-- 2. 比较不同优化器的执行计划
EXPLAIN SELECT /*+ SET_VAR(enable_nereids_planner=true) */ * FROM orders
UNION ALL
EXPLAIN SELECT /*+ SET_VAR(enable_nereids_planner=false) */ * FROM orders;

这两个命令能帮助我们深入了解执行计划的细节差异，特别是在进行查询性能调优时非常有用。

执行计划解读四步法

1. 定位数据源头：找到SCAN类算子，检查是否使用了正确的分区和索引
2. 跟踪数据流向：从下往上分析算子间的数据传递关系
3. 评估代价估算：对比EST.ROWS与实际数据量，判断统计信息是否准确
4. 识别关键算子：重点关注JOIN、AGGREGATE和EXCHANGE算子的属性

🔬 进阶对比：执行计划版本差异深度解析

特性	Legacy Planner	Nereids Planner
优化框架	启发式规则	Cascades基于代价
算子选择	有限固定组合	动态生成最优算子树
统计信息利用	基础表统计	细粒度列级统计
子查询优化	有限支持	复杂子查询重写
并行执行	静态分区	动态资源分配

Nereids Planner作为新一代优化器，在复杂查询场景下通常能生成更优的执行计划。例如对于多表JOIN查询，Nereids能基于实时统计信息动态调整连接顺序，而Legacy Planner则依赖固定的启发式规则。你认为在什么场景下Legacy Planner可能反而表现更好？

🚀 案例分析：从执行计划到算子优化技巧

案例1：消除不必要的数据传输

问题SQL：

SELECT user_id, SUM(amount) 
FROM orders 
GROUP BY user_id 
HAVING SUM(amount) > 1000;

执行计划关键片段：

| 0  | EXCHANGE      | GATHER     | 10000   | ... |
| 1  |  AGGREGATE    | FINAL      | 10000   | ... |
| 2  |   EXCHANGE    | HASH       | 100000  | ... |
| 3  |    AGGREGATE  | PARTIAL    | 100000  | ... |
| 4  |     SCAN      | OLAP_TABLE | 1000000 | ... |

分析：EXCHANGE算子表明存在数据重分布，增加网络开销。通过添加分区过滤条件减少扫描数据量：

SELECT user_id, SUM(amount) 
FROM orders 
WHERE dt >= '2023-01-01'  -- 新增分区过滤
GROUP BY user_id 
HAVING SUM(amount) > 1000;

优化后执行计划消除了中间EXCHANGE算子，查询性能提升60%。

案例2：JOIN算法选择优化

问题SQL：

SELECT o.order_id, c.name 
FROM orders o
JOIN customers c ON o.cust_id = c.id
WHERE o.status = 'PAID';

执行计划关键片段：

| 0  | HASH_JOIN     |            | 50000   | ... |
| 1  |  SCAN         | ORDERS     | 100000  | ... |
| 2  |  SCAN         | CUSTOMERS  | 500000  | ... |

分析：CUSTOMERS表远大于ORDERS表，使用HASH_JOIN效率低下。通过HINT强制使用BROADCAST JOIN：

SELECT /*+ BROADCAST(c) */ o.order_id, c.name 
FROM orders o
JOIN customers c ON o.cust_id = c.id
WHERE o.status = 'PAID';

优化后执行计划将小表ORDERS广播到各节点，避免大表CUSTOMERS的数据传输，查询耗时从120秒降至28秒。

🔧 工具拓展：执行计划分析的辅助工具

执行计划可视化

Doris提供了执行计划图形化展示功能：

EXPLAIN FORMAT=GRAPH SELECT ...;

生成的SVG图形能直观展示算子间的关系和数据流向，特别适合分析复杂查询计划。

高级优化HINT示例

1. 强制使用特定索引：

SELECT /*+ INDEX(t1, idx_date) */ * FROM t1 WHERE date = '2023-01-01';

2. 控制并行度：

SELECT /*+ SET_VAR(parallel_fragment_exec_instance_num=8) */ * FROM large_table;

相关工具推荐

1. Doris Planner Debugger：用于跟踪优化器决策过程的调试工具
2. Query Profiler：记录查询执行的详细 metrics，辅助性能瓶颈定位
3. 统计信息收集工具：定期更新表和列的统计信息，提高执行计划质量

通过这些工具，我们能更深入地理解执行计划的生成过程，掌握算子优化技巧，从而实现查询性能的持续优化。

总结

执行计划分析是Apache Doris查询性能调优的核心技术，通过本文介绍的"数据流水线"模型、四步解读法和实战案例，你已经具备了分析和优化执行计划的基本能力。记住，优秀的SQL性能不是偶然的，而是建立在对执行计划深入理解的基础上。下一次当你遇到查询性能问题时，不妨先问自己：执行计划告诉了我什么？

希望本文能帮助你打开Apache Doris查询优化的大门，在数据分析的道路上走得更远。