SQL无内置weighted_avg()函数，需用SUM(value*weight)/SUM(weight)手动实现，并用NULLIF避免除零错误。
SQL里没有现成的weighted_avg()函数怎么办
绝大多数SQL方言（包括MySQL、PostgreSQL、SQLite）确实不提供内置加权平均聚合函数。你不能直接写 SELECT weighted_avg(score, weight) FROM exams GROUP BY subject——这会报错，比如PostgreSQL抛出 ERROR: function weighted_avg(numeric, numeric) does not exist，MySQL则提示 Unknown function 'weighted_avg'。
本质是加权平均 = Σ(值 × 权重) / Σ(权重)，必须手动拆解为两个聚合再相除。关键不是“能不能算”，而是“怎么组织表达式才不出错”。
常见踩坑点：
- 忘记对分母加
SUM()，写成SUM(value * weight) / weight—— 这实际是每行除以单个权重，结果完全失真 - 权重含
NULL或 0，导致除零错误或聚合被意外过滤（因SUM()忽略NULL，但若全为NULL分母变 0） - 未用
CASE WHEN过滤掉权重 ≤ 0 的行（业务上权重通常应 > 0）
标准写法：用SUM()和COUNT()组合实现
正确公式就是分子用 SUM(value * weight)，分母用 SUM(weight)，两者同级聚合后相除。这是跨数据库最稳的写法。
示例（计算各科目的加权平均分，权重为学时数）：
SELECT subject, SUM(score * hours) / NULLIF(SUM(hours), 0) AS weighted_avg_score FROM courses GROUP BY subject;
这里用了 NULLIF(SUM(hours), 0) 替代裸除，避免除零错误返回 NULL 而非报错。比 CASE WHEN SUM(hours) = 0 THEN NULL ELSE ... END 更简洁。
注意：
-
NULLIF()是标准SQL函数，MySQL 5.7+、PostgreSQL、SQL Server、SQLite 均支持 - 如果权重列本身有
NULL，SUM()自动跳过，无需额外WHERE weight IS NOT NULL（除非你想排除整行） - 若要求严格只统计权重 > 0 的记录，加
WHERE hours > 0更清晰，比在SUM()内套CASE更易读
当权重是百分比（总和为1）或需要归一化时
如果权重列是小数形式（如 0.3, 0.5, 0.2），且保证每组内和为 1，那 SUM(weight) 恒为 1，可省略分母——但别信，先验证。实际数据常有精度误差或漏填，直接写 SUM(value * weight) 隐含风险。
更稳妥的做法是显式归一化：
SELECT
subject,
SUM(score * weight) / SUM(weight) AS weighted_avg_score
FROM (
SELECT
subject,
score,
weight / SUM(weight) OVER (PARTITION BY subject) AS norm_weight
FROM courses
) t
GROUP BY subject;这个写法先用窗口函数把每组权重缩放到和为 1，再聚合。适用于原始权重单位不统一（比如有的用“人数”，有的用“课时”）需统一量纲的场景。但性能略低，因为多了一层子查询和窗口计算。
要点：
- 归一化应在分组前做，否则
SUM() OVER和外层GROUP BY逻辑冲突 - 如果只是补零或修正小数误差，
ROUND(SUM(weight), 6)比强行归一化更轻量
PostgreSQL特供：avg()配合filter不行，但可以用aggregate扩展
PostgreSQL 9.4+ 支持 FILTER 子句，但它只过滤行，不改变聚合逻辑，所以 AVG(x) FILTER (WHERE w > 0) 仍是算术平均，不是加权平均——这点容易误解。
真正可行的是创建自定义聚合函数（一次配置，长期复用）：
CREATE AGGREGATE weighted_avg (numeric, numeric) ( SFUNC = _weighted_avg_transfn, STYPE = numeric[], FINALFUNC = _weighted_avg_finalfn );
但这需要定义状态转换函数和终值函数，涉及数组操作和空值处理，对多数项目属于过度设计。除非团队高频使用加权平均且已有一套UDF管理流程，否则不如坚持手写 SUM(numerator)/SUM(denominator)。
一句话提醒：别被“PostgreSQL功能强”带偏，简单问题用标准语法最可靠。手写公式看似啰嗦，实则所有DBA都看得懂、能审计、易调试。
