SQL中计算加权平均这事儿吧，说简单也简单，说坑也多。通用写法就是 SUM(value * weight) / SUM(weight)，理论上数学定义就是这么翻译过来的。但实际跑起来，真正让你头疼的往往不是公式本身，而是权重数据里的那些 NULL 和 0。
先说个核心判断：这不是某个数据库的特有函数，而是数学定义的直接翻译。所有主流 SQL 引擎——PostgreSQL、MySQL 8.0+、SQL Server、Oracle、SQLite 3.35+——都支持这种写法，而且计算结果完全一致。所以，别费劲去找什么“内置加权平均函数”了，根本没那东西。
通用写法背后的陷阱
关键问题在于：权重是否为零或 NULL。这直接决定你的查询是否会报错，或者结果是否失真。
NULL 权重会被 SUM() 自动忽略，但如果整组权重全是 NULL，情况就麻烦了——SUM(weight) 返回 NULL，整个表达式变成 NULL / NULL，结果仍是 NULL。更危险的是权重为 0 的情况：分母为 0 时，PostgreSQL 直接报错 division by zero，MySQL 默认返回 NULL（如果开启了严格模式，也会报错）。
实际操作中有几个关键点必须注意：
- 务必用
WHERE weight IS NOT NULL AND weight > 0过滤掉无效权重行（需要在GROUP BY之前执行） - 如果业务场景允许权重为 0，改用
NULLIF(SUM(weight), 0)来避免除零错误，比如写成SUM(value * weight) / NULLIF(SUM(weight), 0) - 还要注意
value本身为NULL的情况——value * weight会得到NULL，被SUM()忽略。这通常符合预期，但最好确认一下业务逻辑是否真的要求跳过整条记录
经验表明，加权平均本身逻辑很简单，但权重数据的质量、以及数据库对 NULL/0/类型的处理差异，才是实际跑不通的主因。别急着去查函数文档，先看看你的 weight 列里有没有 NULL、0、负数，以及它的定义类型是否足够容纳乘积结果。
窗口函数的迷思：别被名字骗了
PostgreSQL 和 SQL Server 都支持 A VG() OVER () 这种窗口函数写法，但注意——它只做简单平均，没有提供权重参数。如果你试图写成 A VG(value * weight) OVER (PARTITION BY group_col)，结果大错特错。它算的是“加权值的平均”，而不是“加权平均数”。
举个例子：两行数据——(value=10, weight=1) 和 (value=20, weight=3)。正确加权平均应该是 (10×1 + 20×3)/(1+3) = 17.5；而 A VG(value * weight) 会算成 (10 + 60)/2 = 35，完全牛头不对马嘴。
所以实操建议很明确：
- 抛弃寻找“内置加权平均函数”的幻想，老老实实用
SUM(value * weight) / SUM(weight) - 如果你需要在窗口中计算分组加权平均，仍然得配合
PARTITION BY写完整的表达式：SUM(value * weight) OVER (PARTITION BY group_col) / SUM(weight) OVER (PARTITION BY group_col) - SQL Server 2022+ 虽然引入了
APPROX_PERCENTILE_CONT这类新函数，但它们和加权平均没关系，别搞混了
MySQL 用户的噩梦：隐式类型转换
必须警惕的是，MySQL 在 SUM() 中处理混合类型时，存在一个隐蔽的陷阱。当权重是 INT 类型而值是 DECIMAL 类型时，结果可能被截断小数位——特别是权重是 TINYINT 或 SMALLINT 时。这是因为 SUM(value * weight) 可能先按整型运算，再转换成浮点，精度就这么丢了。
举个例子：value = 1.99，weight = 100，理论上应该得到 199.00。但如果列定义为 DECIMAL(3,2) 乘以 TINYINT，MySQL 很可能返回 199——小数部分直接没了。
解决方法也比较直接：
- 显式转换权重类型：
SUM(CAST(value AS DECIMAL(10,4)) * CAST(weight AS DECIMAL(10,4))) / SUM(CAST(weight AS DECIMAL(10,4))) - 或者在 SELECT 中提前统一类型：
value * 1.0 AS weighted_value，然后再SUM(weighted_value) - 检查执行计划，确认
SUM()的输出类型是否与预期一致——用SHOW COLUMNS查看表结构，或者用SELECT @@sql_mode检查严格模式是否启用
说到底，加权平均这个需求的技术门槛并不高，真正的麻烦往往来自数据质量细节和数据库之间的处理差异。先把手头的权重数据梳理清楚，再动手写 SQL，远比盲目搜索函数文档要高效得多。
