复杂 SQL 查询性能优化：KingbaseES 连接条件下推机制解析

例如，在聚合之前和聚合之后进行过滤，其结果可能完全不同。

因此，优化器必须非常谨慎地判断：

该谓词是否可以安全地下推。

2. 执行成本的评估

即使在语义上允许下推，也不代表一定能够提升性能。

例如，如果谓词被下推后，子查询变成 参数化执行（Parameterized Execution），那么在某些情况下可能会导致子查询被重复执行。

如果外层驱动表的记录数量较大，就可能出现以下情况：

• 子查询执行次数急剧增加
• 总体计算成本反而上升

因此，一个成熟的优化器不仅要判断：

是否可以下推 

还必须判断：

是否值得下推 

二、传统查询优化策略的局限

在许多数据库系统中，为了避免影响查询语义，优化器通常采用比较保守的执行策略。

这种策略通常表现为：

1. 子查询完全执行对底层表进行完整扫描，并完成所有计算逻辑。
2. 生成中间结果子查询结果被完整物化。
3. 外层 JOIN在 JOIN 阶段再应用过滤条件。

这种执行方式通常被称为：

'先计算，后过滤'

当数据规模较小时，这种方式不会带来明显问题。但在数据量较大的场景中，就会产生明显的性能瓶颈：

• 中间结果集过大
• JOIN 阶段计算量增加
• 内存和 I/O 开销上升

因此，如果能够在扫描阶段就进行数据过滤，就可以显著减少系统负担。

三、金仓数据库的优化思路

为了解决上述问题，金仓数据库（KingbaseES） 在最新版本中引入了 基于代价模型的连接条件下推机制。

该优化机制通过两层决策逻辑来保证优化的安全性和有效性。

3.1 第一层：语义等价判断

在执行谓词下推之前，优化器会对 SQL 结构进行详细分析。

主要包括以下步骤：

1. 查询结构识别

优化器会识别子查询中是否存在：

• 聚合函数
• DISTINCT
• 窗口函数
• UNION

如果存在可能影响结果的结构，则需要进一步分析是否允许下推。

2. JOIN 条件拆分

JOIN 条件会被拆解为两个部分：

• 依赖外层表的部分
• 子查询内部列的部分

例如：

s1.a = s2.a 

其中：

• s1.a 来自外层表
• s2.a 来自子查询

优化器会将其转化为子查询内部可使用的过滤条件。

3. 参数化谓词注入

如果语义检查通过，优化器就会将 JOIN 条件转换为 参数化过滤条件，并将其注入到子查询执行阶段。

这样子查询在扫描底层数据时，就可以利用这些条件提前过滤数据。

其核心目标是：

在不改变查询结果的前提下，将过滤操作尽可能提前。

3.2 第二层：基于代价模型的决策

在确认语义安全之后，优化器还需要判断这种优化是否真的有利。

为此，系统会对不同执行方案进行成本估算。

评估内容主要包括：

扫描成本

比较两种执行方式：

• 子查询一次性全量执行
• 子查询根据外层参数多次执行

外层表规模

如果外层表数据量较大，子查询可能被重复执行很多次，从而导致性能下降。

计算与 I/O 成本

优化器会综合考虑：

• CPU 计算量
• 磁盘 I/O
• 数据扫描行数
• 内存使用情况

如果评估结果表明下推会带来性能提升，则优化器才会选择该执行计划。

四、实际测试：性能提升有多明显？

为了验证该优化机制的效果，我们设计了多个测试场景。

4.1 DISTINCT 场景测试

测试 SQL：

SELECT * FROM (SELECT DISTINCT * FROM s3) s3, s1 WHERE s1.s1a = s3.s3a;

执行结果如下：

性能对比：

优化后的执行计划中，JOIN 条件在扫描阶段就发挥了作用，使得：

• 去重数据规模显著减少
• 子查询扫描数据量大幅下降
• 后续 JOIN 开销极低

4.2 极端复杂查询测试

为了进一步验证优化效果，我们构造了一个包含以下特性的 SQL：

• 多层嵌套子查询
• UNION
• DISTINCT
• WINDOW FUNCTION

在未启用优化时，执行流程如下：

1. 左侧子查询进行两次全表扫描
2. UNION 合并结果
3. 执行 DISTINCT 去重
4. 与 s1 进行 JOIN

右侧子查询：

1. 全表扫描
2. GROUP BY
3. 执行窗口函数

最终两个大结果集再进行 JOIN。

执行计划如下：

执行时间：

1081ms 

当启用连接条件下推之后：

• JOIN 条件被注入到各个子查询内部
• 扫描阶段即可进行过滤
• 中间结果集规模显著下降

优化后的执行计划：

执行时间：

0.23ms 

整体性能提升接近：

5000 倍 

五、总结

复杂 SQL 查询的性能问题往往源于一个核心因素：

数据过滤没有在正确的阶段发生。

如果过滤条件能够在数据扫描阶段发挥作用，就可以显著减少中间数据规模，从而提升整体执行效率。

然而，实现这一目标并不简单，因为数据库优化器必须同时解决两个问题：

1. 保证查询语义不变
2. 确保优化能够带来实际收益

金仓数据库通过 语义等价分析 + 成本模型评估 的双重机制，实现了智能的连接条件下推策略，使得复杂查询在保证正确性的前提下获得显著性能提升。

这一优化对于以下场景尤为重要：

• 数据分析型查询
• 复杂报表系统
• OLAP 场景
• 混合负载数据库

随着数据规模不断增长以及 SQL 查询结构日益复杂，基于代价模型的谓词下推技术也将成为未来数据库查询优化器的重要发展方向之一。