加权平均必须用sum(value * weight) / sum(weight)，不能用avg()；需过滤null和零权重，分组时group by不含weight，窗口函数中须手动计算分子分母。
直接用 AVG() 函数无法算加权平均
SQL 标准的 AVG() 只对数值列做简单算术平均，不接受权重参数。想算“某商品销量 × 单价”的加权平均单价，或“学生成绩 × 学分”的加权 GPA，必须手动展开公式：∑(值 × 权重) / ∑(权重)。
常见错误是写成 AVG(value * weight) —— 这算的是「加权值」的平均，不是「加权平均数」，结果完全不对。
标准写法：用 SUM(value * weight) / SUM(weight)
这是跨数据库（PostgreSQL、MySQL 8.0+、SQL Server、Oracle）都支持的写法，语义清晰且无精度陷阱（只要权重非负且不全为零）。
- 确保
weight列不含NULL，否则SUM()会跳过整行，导致分母偏小 → 结果虚高 - 若存在
weight = 0的行，它不影响分母但会让分子贡献为 0，逻辑上合理，可保留 - 如果业务要求排除
weight ≤ 0的记录，显式加上WHERE weight > 0 - MySQL 5.7 或更早版本中，
SUM()遇到全NULL权重会返回NULL，需用COALESCE(SUM(weight), 0)防除零，但更推荐前置过滤
PostgreSQL 和 SQL Server 支持 AVG() OVER () 但不解决加权问题
有人误以为窗口函数能绕过手写求和，其实不能：AVG(value) OVER (PARTITION BY ...) 仍是简单平均；AVG(value * weight) 仍是错的。窗口函数只改变计算范围，不改变平均逻辑本身。
真要结合窗口做分组加权平均（比如每类商品各自的加权均价），仍得写：
SELECT category,
SUM(price * quantity) / NULLIF(SUM(quantity), 0) AS weighted_avg_price
FROM sales
GROUP BY category;
注意用了 NULLIF(SUM(quantity), 0) 替代除零判断，比 CASE WHEN 更简洁安全。
浮点精度与整数截断是隐形坑
当 value 和 weight 都是整数类型（如 INT），多数数据库默认按整数运算：SUM(value * weight) / SUM(weight) 可能被截断为整数（尤其在 PostgreSQL 或 SQL Server 中未显式转换时）。
- 安全做法：把任意一项转为浮点，例如
SUM(CAST(value AS DECIMAL(10,2)) * weight) / SUM(weight) - MySQL 中
DECIMAL更稳，避免FLOAT的二进制精度误差 - 如果原始数据量大、权重分布极不均（比如最大权重比最小大 10⁶ 倍），累加过程可能溢出，需提前检查
value * weight的取值范围
加权平均本身不难，难的是权重来源是否可靠、NULL 怎么处理、整数怎么不丢精度——这些细节一漏，线上报表就悄悄跑偏。
