<p>SQL加权平均值的正确写法是SUM(value * weight) / SUM(weight)，兼容所有主流数据库，语义清晰且天然跳过weight=0或NULL值，需配合WHERE过滤空值并用NULLIF防除零。</p>
SQL加权平均值的正确写法：SUM(value * weight) / SUM(weight)
直接用 SUM(value * weight) / SUM(weight) 是最可靠、兼容性最好的方式，几乎所有主流数据库（PostgreSQL、MySQL 5.7+、SQL Server、Oracle、SQLite）都支持。它不依赖窗口函数或额外聚合层级，语义清晰，且能天然跳过 weight = 0 或 NULL 值（只要你在 WHERE 中处理好空值）。
常见错误是写成 AVG(value) * AVG(weight) 或误用 WEIGHTED AVG（该函数仅 PostgreSQL 16+ 原生支持，且语法为 AVG(value) WITHIN GROUP (ORDER BY weight)，实际并不等价）。
- 务必在分组前过滤掉
weight IS NULL或weight 的行，否则分母为零或结果失真 - 如果
value可能为NULL，建议用COALESCE(value, 0)显式处理，避免整行被排除 - 浮点精度问题：MySQL 默认用 DECIMAL 计算，PostgreSQL 可能返回 double precision；如需固定小数位，外层套
ROUND(..., 2)
GROUP BY 场景下必须注意 NULL 和零权重
加权平均对异常权重极其敏感——一个 weight = 0 不影响分母但让对应 value 白贡献；一个 weight = NULL 则导致整行被 SUM() 忽略，可能意外缩小分母。
典型出错场景：用户表带 score 和 exam_count，想按年级算「总分/总人次」，但部分学生 exam_count 为 NULL（缺考未录入），直接 SUM(score * exam_count) / SUM(exam_count) 会漏掉这些人的 score，但分母变小，结果虚高。
- 安全写法：在
WHERE子句中加上exam_count > 0 AND score IS NOT NULL - 若需保留零权重样本（如标记“计划考试但未执行”），应统一设为
exam_count = 0而非NULL，再用NULLIF(SUM(exam_count), 0)防除零 - 别依赖
HAVING SUM(exam_count) > 0来兜底——它只过滤分组结果，不修复分子计算偏差
MySQL 8.0+ 和 PostgreSQL 的 window 函数不是更优解
有人尝试用 AVG(value) OVER (PARTITION BY group_col ORDER BY weight ROWS UNBOUNDED PRECEDING) 想动态加权，这是误解：窗口 AVG() 算的是简单平均，不接受权重参数。真要用窗口实现加权，仍得手写 SUM(value * weight) OVER (...) / SUM(weight) OVER (...)，反而增加复杂度和计算开销。
- 窗口版本无法替代分组聚合，除非你同时需要组内明细 + 组级加权均值
- 重复计算
SUM(weight) OVER在大数据集上比单次GROUP BY更耗资源 - SQLite 和旧版 MySQL 不支持窗口函数，强行用会直接报错
near "OVER": syntax error
示例：按部门计算薪资加权平均（以职级系数为权重）
SELECT dept, ROUND(SUM(salary * level_weight) / NULLIF(SUM(level_weight), 0), 2) AS weighted_avg_salary FROM employees WHERE level_weight > 0 AND salary IS NOT NULL GROUP BY dept;
这里 NULLIF(SUM(level_weight), 0) 是关键防护：当某部门所有 level_weight 都被 WHERE 过滤后，SUM() 返回 0，NULLIF 将其转为 NULL，避免除零错误，最终该部门结果为 NULL（可读性强于报错）。
真正容易被忽略的是权重单位一致性——比如用「人数」作权重要确保每人只计一次；用「工时」则要确认是否已去重、是否含加班倍数。算出来数字再漂亮，权重量纲错了就全盘失效。
