性能调优实战：数据库连接条件下推原理与案例拆解

引言

在实际的业务系统中，SQL往往并不像教科书示例那样简洁。随着业务复杂度的提升，CTE、多层子查询、窗口函数、聚集计算被大量用于组织逻辑。然而，这类SQL在带来可读性的同时，也给查询优化器带来了巨大的挑战，尤其是在JOIN条件无法有效提前过滤数据的场景下，性能问题尤为突出。

本文将围绕一个在真实客户场景中频繁出现的问题——复杂查询中JOIN条件下推失败导致的性能瓶颈，系统性地介绍一种基于代价模型的连接条件下推（Cost-based Join Predicate Pushdown）的设计与实现思路。

一、问题背景

1.1 客户场景中的典型痛点

在很多客户业务中，SQL通常采用如下模式来组织逻辑：

• 在子查询或CTE中完成大量计算（去重、聚集、窗口函数等）
• 在外层再与其他表进行JOIN，并施加高选择性的过滤条件

例如：

SELECT*FROM(SELECTDISTINCT*FROMs1)sJOINs2ONs.a=s2.aWHEREs2.b=3;

从业务语义上看，这条SQL没有任何问题；但从执行角度看，却隐藏着严重的性能隐患：

• 子查询s需要对s1做全量扫描并去重
• 外层s2.b = 3的高选择性条件，无法影响子查询的扫描范围
• 导致子查询输出一个巨大的中间结果集
• 后续JOIN、聚集等操作都发生在“大数据量”之上，性能急剧下降

根本问题并不在JOIN本身，而在于过滤发生得不够早。

1.2 业界普遍面临的两大难点

将JOIN条件下推到子查询内部，看起来是一个直观有效的优化方向，但在数据库内核层面，这个问题远没有想象中简单，主要体现在两个方面：

1.2.1 语义安全性（Equivalence）

JOIN条件下推，本质上是在改变谓词生效的位置。如果处理不当，很容易改变SQL的语义，尤其是在以下场景中：

• 聚集（GROUP BY）
• 窗口函数（Window Function）
• DISTINCT / UNION
• 含有副作用或非确定性函数的表达式

因此，不是所有JOIN条件都可以安全地下推，必须有严格的等价性判定。

1.2.2 代价评估（Cost）

即便在语义上等价，下推也未必“划算”：

• 下推后可能触发参数化执行
• 外层基数较大时，可能导致子查询被重复执行N次
• 极端情况下，性能反而出现灾难性下降

这意味着：JOIN条件下推不仅要“能推”，还要“值得推”。

二、传统方案的局限

传统优化器在面对上述SQL时，通常会采用如下执行策略：

1. 完整执行子查询：扫描基表，做DISTINCT/UNION/窗口函数等复杂操作
2. 生成一个大的中间结果集
3. 再与外层表进行JOIN，并施加过滤条件

这一策略的致命问题在于：外层的高选择性JOIN/WHERE条件，无法反向约束子查询的扫描范围。当子查询本身计算复杂、数据量大时，这种执行路径几乎必然成为性能瓶颈。

三、金仓数据库基于代价的连接条件下推设计

在金仓数据库最新的V009R002C014版本中，针对上述问题，我们引入了一套“等价性 + 代价模型”双重约束的连接条件下推机制。整体思路可以概括为两步：

3.1 能不能推：等价性判定（Equivalence）

在这一阶段，优化器的目标不是“尽可能多地下推”，而是只识别绝对安全的下推机会：

• 分析子查询结构，判断是否满足语义等价条件
• 对复杂子查询（聚集、窗口、UNION等）进行约束性判定
• 将JOIN条件拆分为：可参数化部分（依赖外层列）和子查询内部列

符合条件的JOIN谓词，会被改写为参数化过滤条件，注入到子查询的扫描或过滤阶段中。

这一步解决的是：“推下去之后，结果会不会变？”

3.2 值不值推：代价模型（Cost）

在通过等价性校验后，并不会立刻选择下推，而是进入代价评估阶段：

• 评估下推前后的执行路径
• 比较子查询扫描行数、中间结果规模
• 评估参数化执行带来的重复计算成本
• 选择整体代价最低的执行计划

如果代价模型判断下推收益不足，甚至可能带来性能回退，则优化器会自动放弃下推，选择其他执行路径。

这一步解决的是：“推下去之后，真的会更快吗？”

3.3 工作流程

下推决策的整体流程如下图所示：

┌─────────────────────────────────────┐ │ 解析JOIN条件 │ └─────────────────────────────────────┘ ↓ ┌─────────────────────────────────────┐ │ Step 1: 等价性判定 │ │ ┌─────────────────────────────┐ │ │ │ 检查子查询结构是否支持下推 │ │ │ │ 拆分谓词为参数化部分和本地部分 │ │ │ └─────────────────────────────┘ │ └─────────────────────────────────────┘ ↓ ┌─────────────────────────────────────┐ │ 是否通过等价性校验？ │ │ ┌──────────┴──────────┐ │ │ 是 否 │ │ ↓ ↓ │ │ ┌───────────────┐ ┌───────────┐ │ │ │ Step 2: 代价评估 │ │ 放弃下推 │ │ │ └───────────────┘ └───────────┘ │ └─────────────────────────────────────┘ ↓ ┌─────────────────────────────────────┐ │ 下推收益是否为正？ │ │ ┌──────────┴──────────┐ │ │ 是 否 │ │ ↓ ↓ │ │ ┌───────────────┐ ┌───────────┐ │ │ │ 执行下推计划 │ │ 保留原计划 │ │ │ └───────────────┘ └───────────┘ │ └─────────────────────────────────────┘

四、效果验证

4.1 最小化用例

首先我们用一个简单的场景来验证下推效果：

SELECT*FROM(SELECTDISTINCT*FROMs3)s3,s1WHEREs1.s1a=s3.s3a;

测试结果：

中间结果规模显著下降，性能提升数量级明显。

作为对比，我们观察某D厂商数据库（不支持下推）的表现：

EXPLAINSELECT/*+use_nl (s3 s1)*/*FROM(SELECTDISTINCT*FROMs3)s3,s1WHEREs1.s1a=s3.s3a;

执行时间约为1.62ms，虽然比未下推的84ms好，但仍远低于金仓下推后的0.14ms。

4.2 复杂场景验证

接下来，我们用一个更复杂的SQL来测试：

EXPLAINANALYZESELECT*FROM(SELECT*FROM(SELECTDISTINCT*FROMs3UNIONSELECTDISTINCT*FROMs3 a)s3,s1WHEREs1.s1d=s3.s3a)sJOIN(SELECT*FROM(SELECTs3a,SUM(s3b)OVER(PARTITIONBYs3a)s3dFROMs3)s3,s1WHEREs1.s1a=s3.s3a)jONs.s3d=j.s3a;

这个SQL包含了UNION、DISTINCT、窗口函数、多层子查询等复杂结构，是真实业务场景的典型代表。

未下推时的执行过程：

1. 左侧子查询处理UNION，左右两侧对基表进行去重全扫描，产生很大的结果集A
2. 结果集A与基表s1连接，产生中间结果集B
3. 右侧子查询对基表s3进行分组并计算窗口函数，得到大的中间结果集C
4. 结果集C与基表s1连接，得到结果集D
5. 最后两个较大的中间结果集B和D进行连接

在这个过程中，子查询几乎需要对表进行全表扫描，耗费大量时间。

下推后的执行过程：

1. JOIN条件提前参与子查询扫描
2. 多个子查询由“全量扫描”转为“选择性扫描”
3. 筛选后的结果集再进行后续的连接操作

性能对比：

性能提升超过4700倍！

这个结果清晰地表明：当我们将连接条件推入子查询后，数据在扫描阶段就被筛选裁剪，大幅减少了扫描时间和后续连接操作的开销，整体查询从全量扫描变为筛选性扫描，带来了质的飞跃。

五、总结

在复杂查询优化中，连接条件下推并不是一个简单的规则改写问题，而是一个典型的成本驱动型优化问题：

• 只做规则，不看代价，可能带来灾难性性能回退
• 只看代价，不保证等价，会直接破坏SQL语义

通过“等价性保障 + 基于代价的决策”的组合设计，我们可以：

• 在安全前提下最大化JOIN条件的过滤能力
• 显著减少子查询阶段的数据扫描与中间结果规模
• 在复杂SQL场景中获得数量级的性能提升

这类优化对于OLAP、混合负载以及复杂报表型查询尤为关键，也将成为未来查询优化器演进的重要方向之一。

写在最后

金仓数据库V009R002C014版本中引入的基于代价的连接条件下推机制，是我们对复杂查询优化的一次深入探索。它不仅仅是简单地“把条件推下去”，而是在确保语义正确的前提下，通过代价模型做出最优决策。

这种设计理念也反映了现代数据库优化器的发展趋势：从基于规则的优化（RBO）走向基于代价的优化（CBO），从单纯的“能做”走向理性的“该做”。

希望本文的分享能对您在复杂SQL性能优化方面的实践有所启发。如果您对金仓数据库的这一特性感兴趣，欢迎下载最新版本进行体验。