窗口函数不能直接嵌套，SQL标准禁止在OVER()中使用窗口函数；必须通过子查询或CTE分步实现，先聚合再开窗。
窗口函数能嵌套吗？不能直接嵌套，但可以分步实现
SQL 标准里不支持像 ROW_NUMBER() OVER (ORDER BY SUM(sales) OVER (PARTITION BY region)) 这种「窗口函数里再套窗口函数」的写法——解析器会报错 Window function is not allowed in window definition。这不是数据库厂商的限制，而是 SQL 标准明确禁止的语法。
真正可行的路径是：先用子查询或 CTE 把内层聚合/计算结果算出来，再在外层对这个中间结果应用窗口函数。
- 别试图在
OVER()里写另一个窗口函数，所有主流引擎（PostgreSQL、MySQL 8+、SQL Server、BigQuery）都会拒绝 - CTE 是最清晰的写法，避免重复计算，也方便调试每一步输出
- 如果性能敏感，注意外层窗口是否需要基于内层已排序/分组的结果；有些场景可改用
GROUP BY + 窗口函数合并步骤
多层级分析典型场景：按地区→城市→时间滚动求和
比如要算「每个城市在各自地区内的累计销售额，且按月递增」，本质是三层逻辑：地区分组 → 城市排序 → 时间累积。必须拆成两步走。
WITH city_monthly AS (
SELECT
region,
city,
sale_month,
SUM(amount) AS monthly_sales
FROM sales
GROUP BY region, city, sale_month
),
region_city_cumsum AS (
SELECT
region,
city,
sale_month,
monthly_sales,
SUM(monthly_sales) OVER (
PARTITION BY region, city
ORDER BY sale_month
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
) AS city_cumsum,
SUM(monthly_sales) OVER (
PARTITION BY region
ORDER BY sale_month, city
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
) AS region_cumsum
FROM city_monthly
)
SELECT * FROM region_city_cumsum;
-
PARTITION BY region, city和PARTITION BY region是不同层级的切片依据，不能混在一个窗口定义里 - 注意
ORDER BY的字段顺序影响累积逻辑：这里先按sale_month再按city，确保同月多个城市有确定顺序 - 如果漏掉
GROUP BY阶段，直接在原始明细行上套多层窗口，结果会因重复行而失真
ORDER BY 里用窗口函数结果？可以，但仅限于外层排序
你不能在 OVER() 里调用窗口函数，但可以在外层查询的 ORDER BY 子句里使用已计算出的窗口函数别名——这是合法且常用的技巧，比如按「各地区的平均销售额排名」后取 Top 3。
- 错误写法：
ORDER BY AVG(sales) OVER (PARTITION BY region)出现在子查询的SELECT里，但没被命名，外层无法引用 - 正确做法：在 CTE 或子查询中把窗口结果起别名（如
region_avg），外层ORDER BY region_avg DESC - 注意 NULL 处理：如果某地区只有 1 行，
AVG()没问题；但若用ROW_NUMBER()分页，需确认PARTITION BY字段无 NULL，否则会被归入同一组
MySQL 8+ 和 PostgreSQL 的兼容性差异点
绝大多数语法一致，但两个细节容易踩坑：
- MySQL 不支持在
WHERE或HAVING中直接引用窗口函数别名（PostgreSQL 支持）；必须用嵌套查询过滤 - PostgreSQL 允许在
GROUP BY后直接用窗口函数（只要不违反逻辑），MySQL 要求窗口函数只能出现在SELECT或ORDER BY - 两者都要求
ORDER BY在窗口定义中显式声明，即使业务上“顺序无关”——不写会报错或返回不确定结果
多层级不是靠一层 SQL 堆砌出来的，而是靠数据形态的逐层收敛：先聚合出稳定粒度，再在这个粒度上划窗。最容易被忽略的是第一步的粒度对齐——region/city/month 必须是明确、无歧义的分组键，否则后续所有窗口结果都是漂移的。
