窗口函数不能嵌套，因执行阶段冲突：LAG等尚未计算时，外层ROW_NUMBER的ORDER BY已需其值，违反SQL执行顺序（SELECT阶段才计算窗口函数），故必然报错。
SQL中嵌套窗口函数（如ROW_NUMBER() OVER (ORDER BY LAG(x, 1))）必然报错，不是数据库版本或写法细节问题，而是执行模型根本禁止——窗口函数只能出现在SELECT或ORDER BY子句中，不能作为另一窗口函数的输入表达式。
为什么LAG()或ROW_NUMBER()不能直接嵌套在另一个窗口函数里？
窗口函数的计算发生在SQL逻辑执行的特定阶段（SELECT阶段），它依赖完整行集和明确的PARTITION BY/ORDER BY上下文。但当你试图把LAG(col)当做一个“值”喂给外层ROW_NUMBER() OVER (ORDER BY ...)时，引擎无法在排序阶段安全求值：LAG还没算出来，ORDER BY却要拿它排序；或者LAG的分区边界与外层不一致，导致语义冲突。
典型错误信息包括：
-
Window function is not allowed in this context（MySQL、SQL Server） -
Invalid use of window function（PostgreSQL） -
ERROR: window function call cannot appear in the ORDER BY clause of another window function（PostgreSQL 明确提示）
如何用CTE或子查询“解嵌套”窗口函数？
核心思路是分层物化：先让内层窗口函数产出确定列，再在外层查询中把它当作普通字段参与计算或过滤。
例如想取“每个用户最新一条订单，并附带该用户订单总数”：
WITH ranked_orders AS (
SELECT
user_id,
order_id,
created_at,
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC) AS rn,
COUNT(*) OVER (PARTITION BY user_id) AS total_orders
FROM orders
),
latest AS (
SELECT user_id, order_id, created_at, total_orders
FROM ranked_orders
WHERE rn = 1
)
SELECT * FROM latest;关键点：
- 必须用
WITH或子查询把rn固化为结果列，否则WHERE rn = 1会报Unknown column 'rn' -
COUNT(*) OVER ()和ROW_NUMBER() OVER ()可以共存于同一SELECT，因为它们各自独立计算，不构成嵌套 - MySQL 要求子查询必须带别名（
AS t），漏掉就报Every derived table must have its own alias
WHERE、GROUP BY、HAVING里为什么不能直接引用窗口函数？
因为SQL执行顺序固定：FROM → WHERE → GROUP BY → HAVING → SELECT（含窗口函数）→ ORDER BY。窗口函数在SELECT阶段才生成，而WHERE等更早阶段根本“看不见”它。
常见错误写法及修正：
- ❌
SELECT * FROM orders WHERE ROW_NUMBER() OVER (ORDER BY id) → 报错：窗口函数不在<code>WHERE合法位置 - ✅ 改成：先用CTE或子查询算出
rn，再外层WHERE t.rn - ❌
SELECT dept, AVG(salary), RANK() OVER (ORDER BY AVG(salary)) FROM emp GROUP BY dept→ 报错：AVG(salary)是聚合函数，不能直接塞进窗口ORDER BY - ✅ 改成：先
GROUP BY dept得均值，再用CTE加RANK() OVER (ORDER BY dept_avg)
容易被忽略的性能与兼容性细节
即使语法通过，执行效率也可能断崖下跌：
- 如果
OVER (PARTITION BY user_id ORDER BY create_time)中create_time没索引，MySQL/PostgreSQL 都会触发Using filesort，百万级数据秒变数秒 - PostgreSQL 11+ 支持
WINDOW w AS (...)复用定义，但所有复用它的窗口函数都强制继承相同PARTITION BY和ORDER BY，若某处不需要排序，也得硬执行——不如拆成两个独立窗口 - OceanBase V4.x 对子查询中含窗口函数特别敏感，报错
-4016往往不是逻辑错，而是优化器在物化子查询时无法共享窗口表达式，必须显式用CTE替代子查询
真正卡住人的，从来不是“会不会写”，而是没想清楚：这个值到底该在哪一层产生、在哪一层消费。窗口函数不是万能胶，强行粘合只会撕开执行计划。
