加权平均值在分组+窗口场景下的真实需求是按组内各行权重动态计算均值，需用SUM(weight*value) OVER(...)/SUM(weight) OVER(...)实现，而非简单AVG()。
什么是加权平均值在分组 + 窗口场景下的真实需求
直接用 AVG() 算不出加权平均——它对每个组内所有行等权处理。当你有类似「按部门统计人均销售额，但每人贡献不同（比如销售量 × 单价）」的需求时，必须手动构造加权逻辑。核心是：分组后，在每组内用 SUM(权重 × 数值) / SUM(权重)，而窗口函数让这个计算能“跨行可见”，比如算当前部门累计加权均值、或带排序的滑动加权均值。
用 SUM() 窗口函数组合实现加权平均的写法
关键不是调用某个现成函数，而是把加权平均拆解为两个窗口聚合：分子用 SUM(weight * value) OVER (...)，分母用 SUM(weight) OVER (...)，再相除。注意：不能在 GROUP BY 后直接套 OVER，因为窗口函数在 GROUP BY 之后执行；所以常见做法是先子查询/CTE 聚合出各组基础数据，再在其上开窗。
- 若需「每个部门内，按入职时间排序，计算截至当前员工的加权平均单价」：
SELECT dept, hire_date, price, qty, SUM(price * qty) OVER (PARTITION BY dept ORDER BY hire_date) * 1.0 / SUM(qty) OVER (PARTITION BY dept ORDER BY hire_date) AS weighted_avg FROM sales; -
* 1.0是为避免整数除法截断（尤其 PostgreSQL/SQL Server 中INT / INT → INT） -
PARTITION BY dept对应分组，ORDER BY hire_date决定窗口边界是否累积；不加ORDER BY则整个部门视为一个窗口，结果每行相同
容易踩的坑：NULL、零权重、精度丢失
加权平均对数据质量敏感，三个高频问题：
-
weight列含NULL或 0：会导致分母为 0 或NULL，建议显式过滤或用NULLIF(SUM(weight), 0)防崩 - 分母为 0 时除法报错（如 PostgreSQL 报
division by zero），SQL Server 报Arithmetic overflow；可改写为：CASE WHEN SUM(weight) OVER (...) = 0 THEN NULL ELSE SUM(weight * value) OVER (...) * 1.0 / SUM(weight) OVER (...) END - 浮点误差：某些引擎（如 MySQL 5.7）对
DECIMAL列做窗口聚合后可能隐式转为DOUBLE，导致小数位异常；明确 cast 分子分母为同精度类型更稳，例如CAST(SUM(weight * value) AS DECIMAL(18,4))
和 GROUP BY + 子查询方式对比选哪个
两种路径都能算加权平均，但适用场景不同：
- 纯分组汇总（如“每个部门最终加权均价”）：用
GROUP BY dept+SUM(price*qty)/SUM(qty)更轻量，无窗口开销 - 需要保留明细行并附加组内统计（如“每个销售单显示其所在部门的加权均价”）：必须用窗口函数，否则得
JOIN聚合结果，多一次扫描 - 涉及动态窗口（前 N 行、范围区间、累计值）：只能靠
OVER (ORDER BY ... ROWS BETWEEN ...)，子查询做不到
真正难的不是写法，是想清楚：你要的是组内静态标尺，还是随行变化的动态参考值——前者别硬套窗口，后者漏掉 ORDER BY 或写错 PARTITION BY 就全偏了。
