一、引言
在数据库理论的学习过程中，我们常常接触到简洁优美的 SQL 示例——单表查询、简单连接、基础过滤，这些案例清晰地展示了关系代数的基本原理。然而，当我们步入真实的业务系统，面对的 SQL 语句往往如同缠绕的线团：公用表表达式 (CTE) 层层嵌套，子查询彼此交织，窗口函数与聚集计算随处可见。
这种复杂性并非开发人员的炫技，而是业务逻辑的自然映射。遗憾的是，这种为提升可读性而组织的 SQL 结构，却给查询优化器带来了严峻考验。在众多性能瓶颈中，有一个问题尤为突出：高选择性的连接条件无法穿透复杂的子查询结构，导致数据过滤发生在错误的时间点。本文将深入探讨这一问题的本质，并介绍一种基于代价模型的连接条件下推解决方案，展示如何让优化器既懂'安全'，又知'成本'。
二、性能困境：过滤迟到的代价
2.1 真实场景的切面分析
在大量客户业务系统中，一种常见的 SQL 编写模式反复出现：开发人员习惯先在子查询或 CTE 中完成复杂的预处理逻辑——去重、排序、窗口计算，然后再将这些预处理结果与其它表进行连接，最后施加过滤条件。从业务语义角度看，这种写法清晰自然；但从执行效率角度看，却暗藏危机。
考虑以下典型场景：某电商平台需要分析特定类目的高价值用户行为。业务人员编写了这样的查询：
WITH user_spending AS (
SELECT user_id, SUM(amount) AS total_amount
FROM orders
GROUP BY user_id
)
SELECT u.user_id, u.total_amount, c.category_name
FROM user_spending u
JOIN categories c ON u.category_id = c.category_id
WHERE c.is_high_value = 1 AND u.total_amount > 10000;
表面上看，这个查询意图明确。但深入执行层面会发现：user_spending CTE 需要扫描所有订单数据，完成分组聚合，生成一个可能极为庞大的中间结果，然后才与外层的 categories 表连接并应用过滤条件。如果 is_high_value = 1 的条件能够过滤掉 99% 的类别，那么意味着 99% 的聚合计算都是徒劳的。
这种'先膨胀后收缩'的执行模式，正是复杂查询性能问题的根源。
2.2 问题根源的双重复杂性
为什么这样一个直观的优化点，在数据库内核实现中却步履维艰？原因在于它触及了查询优化的两个核心难题：
难题一：语义等价性的保障
将连接条件下推到子查询内部，本质上是在重写查询的执行逻辑。这种重写必须保证：无论数据如何分布，重写前后的查询结果完全一致。然而，当子查询中包含以下元素时，语义等价性的判断变得异常复杂：
