加权平均计算需主动过滤null值和零权重，正确写法为where value is not null and weight is not null and weight > 0，并用case when sum(weight) = 0 then null else sum(value * weight) / sum(weight) end防除零。
为什么直接用 SUM(value * weight) / SUM(weight) 有时结果不对
常见错误是忽略 NULL 值的传播：只要 value 或 weight 任一为 NULL，value * weight 就变成 NULL，导致整个 SUM() 结果为 NULL，最终除法失败或返回 NULL。更隐蔽的问题是权重为 0 —— 虽然数学上允许（不参与加权），但某些数据库（如 PostgreSQL）在 SUM(weight) 为 0 时会报除零错误。
- 务必用
WHERE weight IS NOT NULL AND weight != 0 AND value IS NOT NULL过滤掉无效行 - 若业务允许权重为 0，建议显式排除：
weight > 0（比!= 0更安全，避免负权重歧义） - MySQL 中除零默认返回
NULL，而 PostgreSQL 会抛出division by zero错误，需提前防御
不同数据库对空值和除零的处理差异
SUM() 本身会自动跳过 NULL，但乘法运算不会 —— 这是关键分水岭。PostgreSQL 和 SQL Server 对 NULL 严格遵循三值逻辑；MySQL 在某些模式下可能隐式转 0，但不可依赖。
- 安全写法统一用：
SUM(COALESCE(value, 0) * COALESCE(weight, 0))—— 但注意：这会把缺失数据当成 0 参与计算，通常不符合加权平均语义 - 正确做法是先过滤：
WHERE value IS NOT NULL AND weight IS NOT NULL AND weight > 0 - 为防除零，可包装为：
CASE WHEN SUM(weight) = 0 THEN NULL ELSE SUM(value * weight) / SUM(weight) END
带分组的加权平均（例如按部门计算人均绩效得分）
当需要按维度分组时，不能只靠外层 GROUP BY，必须确保每组内权重有效。常见陷阱是某组所有权重都为 0 或全 NULL，导致该组结果为 NULL 或报错。
SELECT
dept,
CASE
WHEN SUM(weight) > 0 THEN SUM(score * weight) / SUM(weight)
ELSE NULL
END AS weighted_avg_score
FROM performance
WHERE score IS NOT NULL AND weight IS NOT NULL AND weight > 0
GROUP BY dept;
-
WHERE条件必须放在GROUP BY之前，否则无效行仍参与分组（只是被SUM()忽略） - 如果希望保留空权重组并显示
0或提示，可改用COALESCE(..., 0)，但需明确业务含义 - 注意浮点精度：SQL Server 默认整数除法截断，需至少一个操作数转为
FLOAT或DECIMAL
性能与索引建议
加权平均本质是两趟聚合（SUM 两次），无法用单列索引加速。但如果频繁按某字段分组计算，可考虑物化中间结果或添加覆盖索引。
- 对高频查询字段（如
dept、period）建立复合索引：CREATE INDEX idx_perf_dept_wt_sc ON performance(dept, weight, score); - 避免在
WHERE中对weight做函数操作（如ABS(weight)），否则索引失效 - 大数据量时，
SUM(value * weight)可能溢出（尤其INT类型），建议显式转为BIGINT或DECIMAL(18,4)
加权平均看着简单，真正落地时最常翻车的是空值穿透和除零边界——别指望数据库替你做业务判断，每一处 NULL 和 0 都得主动拦截。
