引言：当'逻辑清晰'遇上'性能陷阱'
在现代企业级应用中，SQL 早已不再是简单的单表查询。为了应对复杂的业务逻辑，开发人员倾向于使用 CTE（公用表表达式）、嵌套子查询、窗口函数和聚集操作来组织数据流程。这种写法虽然提升了代码的可读性和维护性，却往往给数据库优化器带来了'隐形炸弹'——尤其是在 连接条件无法有效下推到子查询内部 的场景下，中间结果集的膨胀会直接拖垮整个查询性能。
本文从一个真实客户案例出发，深入剖析复杂查询中因连接条件下推失败导致的性能瓶颈，并介绍金仓数据库在 V009R002C014 版本中引入的 基于代价模型的连接条件下推（Cost-based Join Predicate Pushdown） 方案。该方案通过'语义等价性保障'与'代价模型决策'的双重约束，在保证结果正确的前提下，实现了数量级的性能提升。
问题根源：高选择性条件为何'鞭长莫及'
场景还原
在许多业务系统中，SQL 往往呈现以下模式：
- 在子查询或 CTE 中完成复杂的预处理（如去重、聚合、窗口计算）；
- 外层再与其他表进行连接，并附带高选择性的过滤条件。
例如：
SELECT * FROM (
SELECT DISTINCT s1.a, s1.b FROM s1
) s
JOIN s2 ON s.s1a = s2.s2a
WHERE s2.b = 3;
从业务语义上看，这个查询逻辑清晰：先对 s1 去重，再与 s2 连接并过滤 s2.b = 3 的数据。但从执行层面分析，隐患巨大：
- 子查询
s必须对s1执行全表扫描和去重操作； - 外层
WHERE s2.b = 3的高选择性条件无法'穿透'到子查询内部； - 子查询产生一个庞大的中间结果集；
- 后续的连接和过滤全部基于这个大结果集进行，性能急剧下降。
问题的核心并非连接本身，而是 过滤发生得太晚。
业界面临的两大核心难点
将连接条件下推到子查询内部，直观上能有效解决上述问题。但数据库内核实现这一优化，需要跨越两道关卡：
1. 语义等价性（Equivalence）
连接条件下推改变了谓词生效的位置，若处理不当，可能改变 SQL 的最终语义。尤其在以下场景中，下推必须格外谨慎：
- 包含聚集函数（
GROUP BY）或窗口函数； - 存在
DISTINCT、UNION等集合操作； - 涉及非确定性函数或带有副作用的表达式。
因此，并非所有连接条件都能安全下推，必须建立严格的等价性判定规则。
2. 代价评估（Cost）
即便语义上等价，下推也未必总是'划算'：
- 下推后可能将连接转化为参数化执行（Nested Loop 风格），若外层驱动表数据量巨大，子查询会被重复执行成千上万次；
- 极端情况下，参数化执行的累积开销可能超过原始的全表扫描方案，导致性能回退。
结论很明确：连接条件下推不仅要 '能推'，更要 '值得推'。
