复杂 SQL 查询中因过滤条件应用过晚导致的性能瓶颈问题，特别是子查询产生庞大中间结果集的情况。介绍了金仓数据库 KingbaseES V009R002C014 版本引入的基于代价模型的连接条件下推机制。该机制通过语义等价判断和执行代价评估两层决策，确保在保持查询结果正确的前提下，将 JOIN 条件提前注入子查询扫描阶段。测试表明，在 DISTINCT 和极端复杂查询场景下，该优化能带来数百至数千倍的性能提升，显著减少中间数据规模和系统资源消耗，适用于数据分析、报表系统及 OLAP 场景。
在企业级数据库应用不断发展的今天，SQL 的使用场景已经远远超出了最初的简单查询范畴。现实系统中的 SQL 往往承载着复杂的数据处理逻辑，例如统计分析、业务报表、数据聚合与实时分析等。因此，在编写 SQL 时，开发者通常会引入 CTE（Common Table Expression，公用表表达式）、嵌套子查询、窗口函数以及多种聚合操作来组织复杂逻辑，使得 SQL 结构更加清晰、可读性更强。
然而，从数据库执行层面来看，SQL 结构越复杂，对查询优化器的挑战就越大。特别是在涉及 多表关联（JOIN） 的复杂查询中，如果过滤条件没有在数据读取阶段发挥作用，而是等到中间结果生成之后才被应用，那么系统就可能需要处理远远超出实际需求的数据量，导致查询效率大幅下降。
很多数据库工程师在实际项目中都会遇到这样的情况： 某条 SQL 在开发环境执行得很快，但在生产环境却变得异常缓慢。进一步分析执行计划后会发现，问题往往出现在 子查询产生了庞大的中间结果集，而真正具有过滤能力的条件却没有提前参与执行。
针对这一类问题，金仓数据库（KingbaseES） 在 V009R002C014 版本中引入了一项重要优化能力——基于代价模型的连接条件下推（Cost-based Join Predicate Pushdown）。该机制通过'语义等价判断 + 执行代价评估'的方式，在保证查询结果正确的前提下，使复杂 SQL 的执行效率得到显著提升。
接下来，本文将从问题产生的原因入手，逐步介绍这一优化机制的设计思想以及在实际场景中的性能提升效果。
在实际业务系统中，复杂 SQL 通常会呈现出一种典型结构：
例如：
DISTINCTGROUP BY 聚合而真正用于筛选数据的条件，却往往出现在外层 JOIN 中。
从 SQL 语义角度来看，这种写法没有任何问题。但从执行角度来看，如果数据库优化器无法将外层条件提前应用到子查询阶段，就会产生明显的性能问题。
执行过程可能会变成：
这种执行顺序会导致大量无效数据参与计算，系统资源被严重浪费。
换句话说，这类性能问题的本质可以总结为：
过滤条件应用得太晚，数据裁剪没有在早期阶段完成。
从直觉上看，似乎只要把 JOIN 条件'往里推'就可以解决问题。但在数据库优化器设计中，这个过程并不像表面看起来那么简单。
其中主要存在两个关键难点。
数据库优化器必须确保任何优化都不会改变 SQL 的结果。
但在某些结构中，谓词位置的改变可能影响最终结果，例如：
GROUP BYDISTINCTWINDOW FUNCTIONUNION例如，在聚合之前和聚合之后进行过滤，其结果可能完全不同。
因此，优化器必须非常谨慎地判断：
该谓词是否可以安全地下推。
即使在语义上允许下推，也不代表一定能够提升性能。
例如，如果谓词被下推后，子查询变成 参数化执行（Parameterized Execution），那么在某些情况下可能会导致子查询被重复执行。
如果外层驱动表的记录数量较大，就可能出现以下情况：
因此，一个成熟的优化器不仅要判断：
是否可以下推
还必须判断：
是否值得下推
在许多数据库系统中，为了避免影响查询语义，优化器通常采用比较保守的执行策略。
这种策略通常表现为：
这种执行方式通常被称为：
'先计算，后过滤'
当数据规模较小时，这种方式不会带来明显问题。但在数据量较大的场景中，就会产生明显的性能瓶颈：
因此，如果能够在扫描阶段就进行数据过滤，就可以显著减少系统负担。
为了解决上述问题，金仓数据库（KingbaseES） 在最新版本中引入了 基于代价模型的连接条件下推机制。
该优化机制通过两层决策逻辑来保证优化的安全性和有效性。
在执行谓词下推之前，优化器会对 SQL 结构进行详细分析。
主要包括以下步骤：
优化器会识别子查询中是否存在：
如果存在可能影响结果的结构，则需要进一步分析是否允许下推。
JOIN 条件会被拆解为两个部分：
例如：
s1.a = s2.a
其中：
s1.a 来自外层表s2.a 来自子查询优化器会将其转化为子查询内部可使用的过滤条件。
如果语义检查通过，优化器就会将 JOIN 条件转换为 参数化过滤条件，并将其注入到子查询执行阶段。
这样子查询在扫描底层数据时，就可以利用这些条件提前过滤数据。
其核心目标是：
在不改变查询结果的前提下，将过滤操作尽可能提前。
在确认语义安全之后，优化器还需要判断这种优化是否真的有利。
为此，系统会对不同执行方案进行成本估算。
评估内容主要包括：
比较两种执行方式：
如果外层表数据量较大，子查询可能被重复执行很多次，从而导致性能下降。
优化器会综合考虑：
如果评估结果表明下推会带来性能提升，则优化器才会选择该执行计划。
为了验证该优化机制的效果，我们设计了多个测试场景。
测试 SQL：
SELECT * FROM (SELECT DISTINCT * FROM s3) s3, s1 WHERE s1.s1a = s3.s3a;
执行结果如下：
性能对比：
| 执行策略 | 执行方式 | 耗时 | 性能表现 |
|---|---|---|---|
| 未使用下推 | 子查询全量扫描 + 去重 | 约 84ms | 基准 |
| 启用下推 | 扫描阶段提前过滤 | 约 0.14ms | 提升 600 倍 |
| 竞品数据库 | Nested Loop | 约 1.62ms | 无明显优化 |
优化后的执行计划中，JOIN 条件在扫描阶段就发挥了作用，使得：
为了进一步验证优化效果，我们构造了一个包含以下特性的 SQL：
UNIONDISTINCTWINDOW FUNCTION在未启用优化时，执行流程如下：
右侧子查询：
最终两个大结果集再进行 JOIN。
执行计划如下：
执行时间：
1081ms
当启用连接条件下推之后：
优化后的执行计划：
执行时间：
0.23ms
整体性能提升接近：
5000 倍
复杂 SQL 查询的性能问题往往源于一个核心因素：
数据过滤没有在正确的阶段发生。
如果过滤条件能够在数据扫描阶段发挥作用，就可以显著减少中间数据规模，从而提升整体执行效率。
然而，实现这一目标并不简单，因为数据库优化器必须同时解决两个问题：
金仓数据库通过 语义等价分析 + 成本模型评估 的双重机制，实现了智能的连接条件下推策略，使得复杂查询在保证正确性的前提下获得显著性能提升。
这一优化对于以下场景尤为重要：
随着数据规模不断增长以及 SQL 查询结构日益复杂，基于代价模型的谓词下推技术也将成为未来数据库查询优化器的重要发展方向之一。
微信公众号「极客日志」，在微信中扫描左侧二维码关注。展示文案：极客日志 zeeklog
使用加密算法（如AES、TripleDES、Rabbit或RC4）加密和解密文本明文。 在线工具，加密/解密文本在线工具，online
在线格式化和美化您的 SQL 查询（它支持各种 SQL 方言）。 在线工具，SQL 美化和格式化在线工具，online
解析 INSERT 等受限 SQL，导出为 CSV、JSON、XML、YAML、HTML 表格（见页内语法说明）。 在线工具，SQL转CSV/JSON/XML在线工具，online
CSV 与 JSON/XML/HTML/TSV/SQL 等互转，单页多 Tab。 在线工具，CSV 工具包在线工具，online
将字符串编码和解码为其 Base64 格式表示形式即可。 在线工具，Base64 字符串编码/解码在线工具，online
将字符串、文件或图像转换为其 Base64 表示形式。 在线工具，Base64 文件转换器在线工具，online