窗口函数无法直接多维穿透，因其仅支持单一分区和排序；必须先用cube/grouping sets生成多维聚合骨架，再结合grouping()识别层级并分层应用窗口函数。
窗口函数本身不支持“多维度穿透”——它只做跨行计算，不改变分组粒度或生成新维度组合。真要穿透，得先用 GROUPING SETS、CUBE 或 ROLLUP 构建多维聚合骨架，再在结果集上套窗口函数补计算逻辑。
为什么不能直接用窗口函数做多维穿透？
窗口函数的 OVER() 只能定义一个分区（PARTITION BY）和一个排序（ORDER BY），它无法同时按“地区+时间+产品”三个维度切片后再各自算累计值。一旦写成 PARTITION BY region, year, category，就退化为单一层级聚合，和 GROUP BY 效果重叠，且丢失原始明细行——这恰恰违背窗口函数“保行”的初衷。
常见错误现象：
- 写
SUM(amount) OVER (PARTITION BY region, year, category)却发现结果和GROUP BY region, year, category的聚合值一模一样 - 想对 CUBE 生成的“华东+2025+手机”“华东+2025”“2025”多层结果分别算同比，但
LAG()按固定PARTITION BY会跨层级错位
正确做法：先聚合，再窗口
把多维穿透拆成两步：第一步用 CUBE 或 GROUPING SETS 生成所有需要的维度组合；第二步用窗口函数在该宽表上做跨层级计算。关键在于利用 GROUPING() 函数识别当前行所属的聚合层级。
例如，要同时看“各城市销售额”“各省份小计”“全国总计”，并为每层加滚动3月环比：
SELECT
region,
province,
city,
sales_month,
SUM(sales) AS monthly_sales,
GROUPING(region) AS is_region_total,
GROUPING(province) AS is_province_total,
GROUPING(city) AS is_city_total,
-- 在同一层级内按月排序算环比（注意：需先按层级过滤或分条件处理）
LAG(SUM(sales), 1) OVER (
PARTITION BY GROUPING(region), GROUPING(province), GROUPING(city)
ORDER BY sales_month
) AS prev_month_sales
FROM sales_fact
GROUP BY CUBE (region, province, city, sales_month)
HAVING GROUPING(sales_month) = 0; -- 只保留有具体月份的行
要点：
-
GROUPING()返回 1 表示该字段是聚合占位符（如“华东”行里的city是 NULL，但GROUPING(city)=1） -
PARTITION BY GROUPING(x), GROUPING(y)能把相同聚合层级的行归到一起，避免跨层级错位 - 若需不同层级用不同窗口逻辑（如城市层用日环比、省份层用月环比），得用
CASE WHEN分支调用不同OVER()
性能与兼容性必须注意的坑
CUBE 会产生 2n 行，4个维度就是16倍膨胀；加上窗口函数二次扫描，MySQL 8.0+ 和 PostgreSQL 支持较好，但 SQLite、旧版 MySQL 不支持 CUBE，得手写 UNION ALL 模拟。
实操建议：
- 生产环境慎用
CUBE，优先用GROUPING SETS明确列出业务真正需要的组合（比如只要(region, year)和(year)，别全开） - 窗口函数的
ROWS BETWEEN范围在聚合后数据上计算，要确认排序字段（如sales_month）在聚合后仍保持唯一性和连续性，否则LAG()可能跳过空月 - ClickHouse 等 OLAP 引擎对
GROUPING+ 窗口组合优化较好，但 Hive SQL 中GROUPING()常需配合GROUPING_ID()才能精准区分层级
最易被忽略的一点：窗口函数永远作用于当前查询结果集的行序列。如果没意识到 CUBE 输出里同一“省份”可能分散在多行（因其他维度组合不同），直接套 ROW_NUMBER() OVER (PARTITION BY province) 就会漏计或重复计——必须先用 GROUPING() 把“纯省份行”筛出来，再窗口。
