窗口函数不能在外层查询的WHERE、GROUP BY等子句中直接引用，因其执行时机晚于这些子句且上下文在子查询结束后即销毁；必须通过CTE或派生表先固化为物理列才能使用。
窗口函数不能在嵌套查询的外层直接引用，根本原因不是语法禁止，而是 SQL 执行顺序决定了它“还不存在”——外层查询的 WHERE、GROUP BY、甚至同级的 SELECT 列别名，都看不到内层窗口函数计算出的结果。
窗口函数的执行时机早于外层查询解析
SQL 标准规定执行顺序是：FROM → WHERE → GROUP BY → HAVING → SELECT（含窗口函数）→ ORDER BY。这意味着：窗口函数只在内层 SELECT 阶段才被计算；而外层查询的 WHERE 或 SELECT 子句，在逻辑上是在另一个独立的执行阶段运行，无法访问前一阶段生成的列。
常见错误现象：
-
ERROR: column "rn" does not exist—— 在外层写WHERE rn > 1，但rn是内层ROW_NUMBER() OVER()的别名 - 把窗口函数写在子查询的
SELECT中，却试图在外层GROUP BY里用它分组，报错invalid reference to FROM-clause entry
为什么不能像普通列一样“透传”过去
窗口函数不是简单赋值，它依赖完整的行集上下文（如 PARTITION BY dept ORDER BY salary），这个上下文在子查询执行完毕后就销毁了。外层拿到的只是结果集的静态快照，不保留窗口定义信息。
关键限制点：
- 窗口函数结果不能参与外层的
WHERE、HAVING、GROUP BY、ON条件 - 即使子查询用了
AS t别名，外层仍不能把t.rn当作可过滤字段——数据库引擎不会为它生成对应的计划节点 - 某些引擎（如 PostgreSQL）允许在外层
ORDER BY引用，但 MySQL 8.0+ 会直接拒绝：报错Window function is not allowed in this context
替代方案必须显式封装上下文
要让窗口结果可用，必须把它“固化”成物理列，且确保上下文不丢失。可行路径只有两种：
- 用 CTE 封装：先在
WITH t AS (SELECT ..., ROW_NUMBER() OVER(...) AS rn FROM ...)中定义，再SELECT * FROM t WHERE rn > 1—— CTE 本质是命名的子查询，但语义更清晰，优化器也更容易识别重用机会 - 用派生表（子查询 + 别名）：必须把窗口函数放在最内层
SELECT，外层只做投影或过滤，例如：SELECT id, name, rn FROM (SELECT id, name, ROW_NUMBER() OVER(ORDER BY score DESC) AS rn FROM students) AS t WHERE t.rn <= 5
- 避免在子查询里混用窗口函数和
LIMIT：MySQL 会报错Window function is not allowed in this context，因为LIMIT属于结果截断阶段，与窗口计算阶段冲突
嵌套过深时窗口行为更难预测
当视图 A 引用视图 B，B 又包含窗口函数，而你在上层再套一层子查询时，不同数据库处理方式差异很大：
- SQL Server 会递归展开所有视图，最终生成一个扁平查询，但
sp_refreshview不自动更新窗口依赖的排序字段索引 - MySQL 8.0 对多层嵌套中的
OVER()解析可能丢失PARTITION BY范围，导致全表误算 - 如果底层窗口用了
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，而外层又加了WHERE过滤，实际窗口范围会按过滤后数据重算——这不是 bug，是设计使然，但容易被忽略
真正复杂的地方在于：窗口函数的“存在感”只停留在它被定义的那一层 SELECT，跨层传递必须靠显式结构（CTE 或派生表），没有隐式继承，也没有运行时绑定。
