AVG()只能计算等权平均，其逻辑等价于SUM(col)/COUNT(col)，完全忽略权重列；加权平均必须手动实现SUM(value*weight)/SUM(weight)公式，否则结果错误。
为什么直接用 AVG() 算不出加权平均？
因为 AVG() 只对值做等权处理，它内部等价于 SUM(col) / COUNT(col)，完全忽略权重列。你要算「每个值乘以对应权重再求和，最后除以权重总和」，就得手动构造分子分母——这是加权平均的本质公式：SUM(value * weight) / SUM(weight)。
常见错误是写成 AVG(value * weight)，这会先乘再取平均，相当于给每个 value * weight 赋了相同权重（即隐含除以行数），结果严重偏高，尤其当权重差异大时。
- 必须确保权重列不含
NULL或负值，否则SUM(weight)可能为 0 或负，导致除零错误或逻辑错误 - 如果某行
weight为 0，它对分子无贡献，但也不该参与分母计算——不过多数场景下，weight = 0的行本就该被过滤掉 - 用
WHERE weight > 0预过滤比在聚合里加CASE更高效
PostgreSQL / MySQL 8.0+ / SQL Server 中的标准写法
这些引擎都支持标准 SQL 聚合，直接写即可，无需扩展函数：
SELECT SUM(score * credits) / NULLIF(SUM(credits), 0) AS wavg_score FROM courses;
NULLIF(SUM(credits), 0) 是关键：避免分母为 0 报错，返回 NULL 更安全。不要用 CASE WHEN SUM(credits) = 0 THEN NULL ELSE ... END，语义等价但更啰嗦。
- MySQL 5.7 及更早版本不支持窗口函数内嵌聚合，但此处不需要窗口，所以写法一致
- PostgreSQL 对
NUMERIC类型权重更友好，自动保留小数精度；MySQL 默认可能截断，建议显式CAST(score AS DECIMAL) - 如果
score或credits含NULL，整行会被SUM()忽略（符合预期），但最好提前WHERE score IS NOT NULL AND credits IS NOT NULL
SQLite 和旧版 MySQL 中的兼容性注意点
SQLite 支持 SUM() 和除法，但默认整数除法会截断小数——比如 7 / 2 得 3。必须至少一侧转浮点：
SELECT CAST(SUM(score * credits) AS REAL) / NULLIF(SUM(credits), 0) FROM courses;
旧版 MySQL（如 5.6）同理，score 和 credits 若都是整型，除法结果也是整型。不能只靠数据库配置改，得在 SQL 层控制。
-
1.0 * SUM(...)也行，但不如CAST(... AS REAL)明确 - SQLite 没有
NULLIF()函数，得手写：CASE WHEN SUM(credits) = 0 THEN NULL ELSE SUM(score * credits) / CAST(SUM(credits) AS REAL) END - 所有引擎中，
AVG()都无法替代该模式——别试图用它绕开
性能瓶颈通常不在公式本身，而在数据准备
加权平均计算本身是 O(n) 单次扫描，非常快。慢的地方往往是：没走索引的 WHERE 条件、大表未分区、或权重列存在大量 NULL 导致 SUM() 内部跳过判断开销增大。
- 如果频繁按不同维度（如按学期、院系）算加权平均，考虑提前建物化视图或汇总表，而不是每次实时聚合
- 权重列上建索引一般无意义——
SUM()必须扫全表，索引对聚合帮助极小 - 真正要优化的是过滤条件：比如
WHERE semester = '2024-Fall'是否能命中索引？这比纠结用不用WAVG()函数重要得多
加权平均没有银弹函数，核心就是分子分母两步 SUM，但每一步的 NULL 处理、类型转换、分母保护，都得亲手写清楚——漏掉任一环节，结果就不可信。
