窗口函数不能生成多级汇总行，仅能在现有行上添加计算列；多级汇总需先用GROUP BY或ROLLUP产出多层结果集，再用窗口函数补充占比、排名等指标。
窗口函数本身不生成多级汇总行，它只能在已有行上追加计算列；真正做多级汇总（比如明细 + 部门小计 + 公司总计），必须先用 GROUP BY 或 ROLLUP 产出多层结果集，再用窗口函数补全占比、排名、累计值等辅助指标。
为什么不能只靠 SUM() OVER 实现层级小计？
因为 SUM() OVER (PARTITION BY dept) 只是在原表每行旁加一列“本部门总和”，行数不变，不会自动插入小计行。报表里看到的“小计”是聚合后新产生的行，不是窗口函数生成的。
- 窗口函数运行在
GROUP BY之后（逻辑执行顺序），但不改变行数 -
ROLLUP(region, dept, team)才能生成 NULL 占位的汇总行，共 2³ = 8 层组合（含全表总计） - 直接对原始明细表套
SUM() OVER，结果里没有“部门小计”这一行，只有“每个员工所在部门的总销售额”
GROUPING() 是识别 ROLLUP 汇总行的唯一可靠方式
ROLLUP 输出的 NULL 不是数据缺失，而是层级标记。比如 dept 列为 NULL 且 GROUPING(dept) = 1，说明这是 region 级小计行。
PostgreSQL 18.4 ubuntu
下载
PostgreSQL 18.4 官方 Ubuntu 安装包现已发布，这是目前最新的稳定版本。推荐通过官方 APT 仓库安装：先执行 sudo apt update 更新索引，再运行 sudo apt install postgresql-18 即可完成部署。新版本引入了异步 I/O 子系统，在顺序扫描与 VACUUM 场景下性能提升显著，同时支持 UUID v7 原生生成函数与虚拟生成列。
- 别写
WHERE dept IS NOT NULL—— 会把所有小计行过滤掉 - 正确做法：
CASE WHEN GROUPING(dept) = 1 THEN 'region_total' ELSE dept END -
GROUPING(region, dept, team)返回一个位掩码整数，可配合BITAND()拆解多维状态（PostgreSQL 支持）
在 ROLLUP 结果上用窗口函数补全层级占比
有了 GROUP BY region, dept, team WITH ROLLUP 的结果集，才能安全地加窗口函数算“占上级的比例”或“同级排名”。
- 算每个 team 占所属 dept 的比例：
SUM(sales) / SUM(sales) OVER (PARTITION BY region, dept) - 注意分母必须用
OVER (PARTITION BY region, dept)，不能漏掉region—— 否则跨 region 混算 - 给 dept 小计行排名（按总 sales 降序）：
RANK() OVER (ORDER BY SUM(sales) DESC) FILTER (WHERE GROUPING(team) = 1 AND GROUPING(dept) = 0) - PostgreSQL 13+ 支持
FILTER子句，可精准限定窗口计算范围，避免先WHERE再聚合导致丢失汇总行
递归 CTE + 窗口函数处理动态树形分类
当分类层级不固定（如电商类目“一级 > 二级 > 三级…”），ROLLUP 失效，必须先用递归 CTE 展平树，再聚合 + 窗口计算。
- 递归部分必须限制深度：
WHERE depth ，否则环状数据（A→B→A）会死循环 - 关键字段要保留：
root_id（最上级 ID）、path（如 '/电子/手机/苹果'）、depth - 后续聚合时，按
root_id分组算总销售额，再用SUM(sales) OVER (PARTITION BY root_id)补全大类占比 - 索引建议：在
categories(parent_id, id)上建联合索引，加速递归 JOIN
真正难的不是写对窗口函数语法，而是分清“哪些该由聚合产生新行，哪些该由窗口函数追加列”——混用 GROUPING SETS 和 OVER 时，稍不注意就会让汇总行和明细行的计算基准错位。
