引言
在现代企业级应用中，SQL 查询早已超越了简单的单表检索。为了应对复杂的业务逻辑，开发人员广泛使用 CTE（公用表表达式）、多层嵌套子查询、窗口函数以及聚集计算来组织代码。这种写法虽然提升了逻辑的可读性和模块化程度，却给数据库查询优化器带来了严峻挑战。
特别是在涉及多表关联（JOIN）的场景中，如果高选择性的过滤条件无法在数据扫描阶段生效，而是等到生成巨大的中间结果集后才发挥作用，查询性能往往会呈现断崖式下跌。本文将深入剖析这一痛点，并详细介绍金仓数据库（KingbaseES）在最新 V009R002C014 版本中推出的基于代价模型的连接条件下推（Cost-based Join Predicate Pushdown）机制，探讨如何通过“等价性判定 + 代价评估”的双重保障，实现复杂查询的性能飞跃。
一、痛点直击：为何复杂查询会“变慢”？
1.1 典型业务场景的陷阱
在许多实际业务中，SQL 往往遵循以下模式：
- 内层计算繁重：在子查询或 CTE 中执行去重（DISTINCT）、聚合（GROUP BY）、窗口函数等耗时操作。
- 外层过滤滞后：在外层 JOIN 时施加高选择性的过滤条件（如
s2.b = 3）。
执行隐患：
从语义上看，这类 SQL 完全正确。但从执行计划看，优化器若无法将外层的过滤条件下推至内层，会导致：
- 子查询被迫对基表进行全量扫描并完成所有复杂计算。
- 生成一个庞大的中间结果集。
- 后续的 JOIN 和过滤操作都在这个“大数据集”上进行，造成资源浪费和响应延迟。
核心矛盾：过滤发生得太晚，数据裁剪未能提前介入。
1.2 业界优化的两大拦路虎
将 JOIN 条件下推到子查询内部看似直观，但在数据库内核实现上极具挑战：
- 语义安全性（Equivalence）：
盲目下推可能改变查询结果。例如，在存在GROUP BY、WINDOW FUNCTION、UNION或非确定性函数时，谓词的位置变化可能导致结果集行数或内容发生变化。优化器必须能够精准识别哪些条件下推是绝对安全的。 - 代价评估（Cost）：
即使语义安全，下推也不一定划算。- 下推可能引入参数化执行（Parameterized Scan）。
- 若外层驱动表基数较大，可能导致子查询被重复执行 N 次，引发“爆炸式”计算。
- 结论：优化不仅要解决“能不能推”，更要解决“值不值得推”。
二、传统方案的局限
面对上述场景，传统优化器通常采取保守策略：
- 物化子查询：完整执行子查询内的所有逻辑（扫描、去重、窗口计算）。
- 生成大中间集：将子查询结果暂存。
- 后期过滤：再与外层表进行 JOIN 并应用过滤条件。
这种“先算后滤”的模式，使得外层的高选择性条件无法反向约束内层的扫描范围。当子查询涉及海量数据时，这种执行路径必然成为性能瓶颈。
三、金仓数据库的破局之道：双重约束机制
在金仓数据库 V009R002C014 版本中，我们引入了一套创新的"等价性 + 代价模型"双重约束机制，旨在智能决策连接条件的下推策略。
3.1 第一道防线：等价性判定（能不能推？）
优化器首先进行严格的语义分析，确保下推不会改变 SQL 的业务含义：
- 结构分析：识别子查询类型（是否包含聚集、窗口、UNION/DISTINCT 等）。
- 谓词拆分：将 JOIN 条件拆解为“依赖外层列的参数化部分”和“子查询内部列部分”。
- 安全注入：仅当判定满足严格等价条件时，才将符合条件的谓词改写为参数化过滤条件，注入到子查询的扫描或过滤阶段。
目标：确保“推下去之后，结果绝不变”。
3.2 第二道防线：代价模型（值不值推？）
通过等价性校验后，优化器进入代价评估阶段，模拟不同执行路径的成本：
- 全量 vs. 参数化：对比“全量扫描子查询”与“参数化重复扫描”的总开销。
- 基数估算：评估外层驱动表的行数，计算子查询可能被执行的次数。
- IO 与 CPU 权衡：综合考量扫描行数减少带来的收益与重复计算带来的成本。
若模型预测下推会导致性能回退，优化器将自动放弃该策略，选择更优的执行计划。
目标：确保“推下去之后，真的会更快”。
四、实战验证：数量级的性能提升
4.1 基础场景：DISTINCT 下的下推效果
测试 SQL：
Select * from (select distinct * from s3) s3, s1 where s1.s1a = s3.s3a;
测试结果对比：
| 策略 | 执行行为 | 耗时 | 性能提升 |
|---|---|---|---|
| 未下推 | 子查询全表扫描 + 全局去重 -> 大结果集 JOIN | ~84ms | - |
| 下推后 | JOIN 条件提前裁剪扫描范围 -> 小结果集去重 | ~0.14ms | 600倍+ |
| **竞品 D **(无下推) | 强制 Nested Loop 但无法裁剪内层 | ~1.62ms | - |
分析：下推后，子查询在扫描阶段即利用 s1.s1a 的值进行过滤，避免了无效数据的去重计算，中间结果规模急剧缩小。
4.2 复杂场景：多重嵌套、UNION 与窗口函数
测试 SQL：
包含 UNION、DISTINCT、Window Function 及多层子查询的复杂关联。
执行路径对比：
- 未下推时：
- 左侧子查询：对基表全量扫描两次（UNION 两侧）-> 去重 -> 生成大结果集 A -> 与 s1 连接生成 B。
- 右侧子查询：对基表全量扫描 -> 分组 + 窗口计算 -> 生成大结果集 C -> 与 s1 连接生成 D。
- 最终连接：大结果集 B 与 D 进行 JOIN。
- **总耗时：1081ms**
- 下推后：
- 连接条件被推入各个子查询内部。
- 所有基表扫描均变为选择性扫描（Index Seek/Filter Pushdown）。
- 中间结果集 A、C 大幅减小，后续连接开销忽略不计。
- **总耗时：0.23ms**
结论：在极端复杂的 SQL 场景下，基于代价的下推策略将执行时间从秒级降低至毫秒级，实现了近 5000 倍的性能提升。
五、总结
在复杂查询优化中，连接条件下推并不是一个简单的规则改写问题，而是一个典型的成本驱动型优化问题：
- 只做规则，不看代价，可能带来灾难性性能回退；
- 只看代价，不保证等价，会直接破坏 SQL 语义。
通过 “等价性保障 + 基于代价的决策” 的组合设计，我们可以：
- 在安全前提下最大化 JOIN 条件的过滤能力
- 显著减少子查询阶段的数据扫描与中间结果规模
- 在复杂 SQL 场景中获得数量级的性能提升
这类优化对于 OLAP、混合负载以及复杂报表型查询尤为关键，也将成为未来查询优化器演进的重要方向之一。
