SQL中的Window函数用于对查询结果集的指定窗口范围做聚合、排序等计算，很多开发者在编写多层嵌套查询时，会尝试在内层子查询中直接引用外层定义的Window函数计算结果，这种写法通常会导致语法错误或逻辑异常，这和SQL的执行顺序、Window函数的计算特性直接相关。
SQL语句的标准执行顺序
要理解为什么嵌套查询不能引用外部Window函数，首先需要明确SQL的标准执行顺序，不同子句的计算优先级是固定的：
- FROM：确定查询的数据源，包括表关联操作
- WHERE：对数据源的记录做过滤筛选
- GROUP BY：对过滤后的记录做分组
- HAVING：对分组后的结果做过滤
- SELECT：选择需要返回的列，此时才会计算SELECT中定义的Window函数
- DISTINCT：对SELECT的结果去重
- ORDER BY：对最终结果做排序
- LIMIT：限制返回的记录数量
可以看到，Window函数的计算发生在SELECT子句阶段，而嵌套查询中的子查询属于FROM或者WHERE等更早执行的阶段，子查询执行时外层还没有计算Window函数，自然无法引用相关结果。
Window函数的计算窗口限制
Window函数的计算依赖于OVER()子句定义的窗口范围，窗口范围是针对当前查询层的临时结果集生效的，不会跨查询层级传递。外层的Window函数是针对外层查询结果集定义的，内层子查询的结果集和外层的结果集属于不同的作用域，无法共享窗口计算上下文。
比如以下错误示例，内层子查询尝试引用外层的Window函数计算结果：
-- 错误示例：内层子查询引用外层Window函数
SELECT
t.id,
t.score,
t.rank_val
FROM (
SELECT
id,
score,
rank_val -- 内层子查询没有定义rank_val，直接引用外层的Window函数结果
FROM student
WHERE rank_val > 3 -- 此时外层还未计算rank_val，执行报错
) t
JOIN (
SELECT
id,
RANK() OVER (ORDER BY score DESC) AS rank_val
FROM student
) r ON t.id = r.id
上述示例中，子查询t的WHERE子句执行时，外层查询的RANK()函数还没有计算，所以无法识别rank_val这个列，执行时会直接抛出列不存在的错误。
正确的替代实现方案
如果需要在嵌套查询中使用Window函数的结果，应该先在外层或者同层完成Window函数计算，再把结果作为子查询的数据源传递给内层使用，符合执行顺序的规则。
方案一：先算Window函数再做过滤
把Window函数的计算和过滤逻辑放在同一层，或者先计算完Window函数再作为子查询被外层引用：
-- 正确示例：先计算Window函数再做过滤
SELECT
id,
score,
rank_val
FROM (
-- 子查询内先计算Window函数
SELECT
id,
score,
RANK() OVER (ORDER BY score DESC) AS rank_val
FROM student
) t
WHERE t.rank_val > 3 -- 此时子查询已经计算完rank_val，可以正常过滤
方案二：多层嵌套时逐层传递Window结果
如果有多层嵌套需求，每一层需要用到Window函数结果时，都在当前层先计算，再传递给下一层：
-- 多层嵌套的正确示例
SELECT
final_id,
final_score,
final_rank
FROM (
SELECT
t.id AS final_id,
t.score AS final_score,
t.rank_val AS final_rank,
t.class_id
FROM (
-- 最内层先算Window函数
SELECT
id,
score,
class_id,
RANK() OVER (PARTITION BY class_id ORDER BY score DESC) AS rank_val
FROM student
) t
WHERE t.rank_val <= 5 -- 第一层过滤
) tt
WHERE tt.class_id IN (1,2) -- 第二层过滤
常见误区说明
有些开发者会误以为Window函数和普通聚合函数一样可以在子查询中引用，实际上普通聚合函数如果用在子查询中，是作为子查询的聚合结果存在的，而Window函数不会压缩行数，是和原有行一一对应的计算结果，必须和当前查询的结果集绑定，无法跨层级引用。
另外需要注意，OVER()子句中的PARTITION BY、ORDER BY等参数，也只能引用当前查询层的列，不能引用外层查询的列，这也是窗口作用域限制的一部分。