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

引言

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

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

一、问题背景

1.1 客户场景中的典型痛点

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

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

例如：

sql 复制代码

SELECT *
FROM (SELECT DISTINCT * FROM s1) s
JOIN s2 ON s.a = s2.a
WHERE s2.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时，通常会采用如下执行策略：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.3 工作流程

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

vbnet 复制代码

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

四、效果验证

4.1 最小化用例

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

sql 复制代码

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

测试结果：

执行模式	执行时间	说明
未下推	84ms	子查询全表扫描 + 去重
下推后	0.14ms	子查询扫描阶段被JOIN条件裁剪

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

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

sql 复制代码

EXPLAIN SELECT /*+use_nl (s3 s1)*/ * 
FROM (SELECT DISTINCT * FROM s3) s3, s1 
WHERE s1.s1a = s3.s3a;

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

4.2 复杂场景验证

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

sql 复制代码

EXPLAIN ANALYZE
SELECT *
FROM (
    SELECT *
    FROM (SELECT DISTINCT * FROM s3 UNION SELECT DISTINCT * FROM s3 a) s3, s1
    WHERE s1.s1d = s3.s3a
) s
JOIN (
    SELECT *
    FROM (
        SELECT s3a, SUM(s3b) OVER (PARTITION BY s3a) s3d
        FROM s3
    ) s3, s1
    WHERE s1.s1a = s3.s3a
) j ON s.s3d = j.s3a;

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

未下推时的执行过程：

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

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

下推后的执行过程：

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

性能对比：

执行模式	执行时间	扫描方式
未下推	1081ms	全量扫描
下推后	0.23ms	选择性扫描

性能提升超过4700倍！

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

五、总结

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

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

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

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

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

写在最后

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

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

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