复杂查询中 JOIN 条件下推失败导致的性能瓶颈-金仓数据库

文章目录

- 前言
- 一、问题背景
- - [1.1 客户场景中的典型痛点](#1.1 客户场景中的典型痛点)
  - [1.2 业界普遍面临的两大难点](#1.2 业界普遍面临的两大难点)
  - - [1.2.1 语义安全性（Equivalence）](#1.2.1 语义安全性（Equivalence）)
    - [1.2.2 代价评估（Cost）](#1.2.2 代价评估（Cost）)
- 二、传统方案的局限
- - [2.1 完整执行子查询](#2.1 完整执行子查询)
  - [2.2 生成庞大的中间结果集](#2.2 生成庞大的中间结果集)
  - [2.3 再与外层表进行 JOIN](#2.3 再与外层表进行 JOIN)
- 三、金仓数据库基于代价的连接条件下推设计
- - [3.1 能不能推：等价性判定（Equivalence）](#3.1 能不能推：等价性判定（Equivalence）)
  - [3.2 值不值推：代价模型（Cost）](#3.2 值不值推：代价模型（Cost）)
  - [3.3 详细工作流程](#3.3 详细工作流程)
- 四、效果验证
- - [4.1 最小化用例](#4.1 最小化用例)
  - [4.2 复杂场景验证](#4.2 复杂场景验证)
- 五、总结

前言

在实际的企业级业务系统里，SQL 语句往往远比教科书上的示例要复杂得多。随着业务逻辑不断演进，CTE（公共表表达式）、多层嵌套子查询、窗口函数、聚合运算等技术被广泛采用，以提升代码的可读性与可维护性。然而，这些高级特性在带来开发便利的同时，也给查询优化器带来了前所未有的挑战。特别是在 JOIN 条件无法提前对数据进行过滤的场景下，性能问题会变得尤为严峻。

本文将聚焦于一个在真实客户环境中频繁出现的经典难题------复杂查询中 JOIN 条件下推失败导致的性能瓶颈 ，系统化地阐述一套 基于代价模型的连接条件下推 方案的设计思路与实现方法。

一、问题背景

1.1 客户场景中的典型痛点

在众多客户的业务系统里，SQL 语句通常呈现出以下典型的结构模式：

先在子查询或 CTE 中完成大量的数据处理工作，包括去重、聚合、窗口函数计算等；
然后在外层将这些中间结果与其他表进行 JOIN，并在 JOIN 过程中施加高选择性的过滤条件。

从业务语义的角度来看，这类 SQL 完全没有问题；但从执行性能的角度审视，却隐藏着严重的性能隐患：

子查询需要对底层基表进行全量扫描并完成去重操作；
外层的高选择性条件（如 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）

即便在语义上完全等价，下推操作也未必"划算"：

下推后可能触发参数化执行（Parametric Execution）；
当外层基数较大时，可能导致子查询被重复执行 N 次；
在极端情况下，性能反而会出现灾难性的下降。

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

二、传统方案的局限

传统查询优化器在面对上述类型的 SQL 时，通常会采用以下执行策略：

2.1 完整执行子查询

扫描底层基表；
执行 DISTINCT / UNION / 窗口函数等复杂操作。

2.2 生成庞大的中间结果集

子查询处理完成后，会生成一个体积巨大的中间结果集。

2.3 再与外层表进行 JOIN

最后，在已经膨胀的中间结果之上施加过滤条件并完成 JOIN。

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

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

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

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

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

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

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

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

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

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

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

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

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

3.3 详细工作流程

整体工作流程如图所示:

四、效果验证

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。

4.2 复杂场景验证

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;

在包含 UNION、DISTINCT、窗口函数、多层子查询的复杂 SQL 场景中：

未下推时

多个子查询对基表进行全量扫描；
生成多个体积庞大的中间结果集；
最终的 JOIN 成为性能瓶颈。

下推后

JOIN 条件提前参与子查询扫描；
多个子查询从"全量扫描"转变为"选择性扫描"；
整体执行时间从 1081ms 降至 0.23ms。

深入分析

当连接条件不下推时，系统需要先处理内部的 UNION 查询，且 UNION 的左右两侧都对基表进行去重全扫描，产生一个很大的结果集 A；然后与基表 s1 进行连接，产生中间结果集 B。接着执行右侧子查询，对基表 s3 进行分组并计算窗口函数，得到一个大型中间结果集 C，再与基表 s1 进行连接得到结果集 D。最后，两个较大的中间结果集 B 和 D 进行连接。在这个过程中，子查询几乎需要对表进行全表扫描以获取数据，耗费大量时间，导致性能极差。

当我们实现将连接条件推入子查询后，可以利用连接条件下推的优势，在子查询的数据扫描阶段就被筛选裁剪，减少扫描时间。筛选后的结果集在进行后续的连接操作时，可以显著减少连接操作的时间。整体查询从全量扫描变为筛选性的扫描，带来性能上的质的飞跃------从未下推的 1081ms 变为下推后的 0.23ms。

五、总结

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

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

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

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

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