<p>加权平均数必须用SUM(value * weight) / SUM(weight)，不能用AVG()；需配合GROUP BY，用NULLIF防除零，并确保权重非NULL且类型正确。</p>
SQL视图里直接用 SUM() 和 AVG() 算不出加权平均数
加权平均数不是 AVG(weighted_value)，而是「各值 × 对应权重之和」除以「权重总和」。SQL 的 AVG() 默认等权，强行套用会得到错误结果。比如成绩表里数学占 40%、英语占 60%，直接 AVG(score) 就把两科当成各占 50% 处理了。
正确做法是手动展开分子分母：分子用 SUM(score * weight)，分母用 SUM(weight)，再相除。
- 权重字段必须为数值型（不能是字符串或 NULL，否则
SUM()结果异常） - 若某行权重为 0，它对分子无贡献，但会拉低分母——需确认这是否符合业务逻辑（例如“未参与考核”该不该计入分母）
- 除零风险：当所有
weight全为 NULL 或 0 时，SUM(weight)返回 NULL，整除式结果为 NULL；必要时加CASE WHEN SUM(weight) = 0 THEN NULL ELSE ... END
在 CREATE VIEW 中写加权平均的典型结构
视图定义里不能用子查询包裹聚合（多数数据库不支持），所以必须在 SELECT 列表中直接计算。关键就是两个 SUM() 套一层除法。
CREATE VIEW student_weighted_avg AS SELECT class_id, SUM(score * weight) / NULLIF(SUM(weight), 0) AS weighted_avg_score FROM exam_scores GROUP BY class_id;
NULLIF(SUM(weight), 0) 是安全写法：当分母为 0 时返回 NULL，避免报错。比 CASE WHEN 更简洁，且兼容 PostgreSQL、SQL Server、MySQL 8.0+ 和 SQLite。
- MySQL 5.7 及更早版本不支持
NULLIF在聚合后直接使用，此时改用CASE WHEN SUM(weight) = 0 THEN NULL ELSE SUM(score * weight) / SUM(weight) END - 如果权重是百分比（如 0.4、0.6），结果直接是加权平均；如果是计数类权重（如考试次数、学时数），结果物理意义是「总得分 / 总权重」，仍属加权平均范畴
- 注意数据类型：若
score和weight都是整数，除法可能截断。显式转成DECIMAL或乘 1.0 强制浮点，例如SUM(score * weight * 1.0) / NULLIF(SUM(weight), 0)
WHERE 条件和 NULL 值会显著影响结果
加权平均对缺失值敏感。只要 score 或 weight 任一列为 NULL，整行在 SUM(score * weight) 和 SUM(weight) 中都会被忽略——这是 SQL 聚合的默认行为，但未必符合预期。
- 想排除
score IS NULL的行，但保留weight IS NULL的行？不行。score * weight遇到任一 NULL 就得 NULL，进而被SUM()忽略 - 常见误操作：先
WHERE score IS NOT NULL，以为就够了。但如果weight有 NULL，这些行照样不参与计算，导致分母偏小、结果虚高 - 稳妥做法是在视图外层或 ETL 阶段补全权重（如设默认值 1）或明确过滤条件：
WHERE score IS NOT NULL AND weight IS NOT NULL AND weight > 0
性能与索引注意事项
视图本身不存数据，但每次查询都重算 SUM()。如果底表很大，且加权平均只针对少数字段组合，考虑提前物化（如 PostgreSQL 的物化视图、MySQL 的汇总表）。
- 数据库无法用单字段索引加速
SUM(score * weight)，因为这是表达式。若频繁按class_id查加权平均，确保class_id有索引即可 - 复合索引
(class_id, score, weight)可能提升 GROUP BY 性能（覆盖索引避免回表），但收益取决于数据分布和数据库优化器 - 权重大范围变动（如从 0.1 到 1000）可能导致浮点精度误差，尤其在大量小权重 + 极大权重混杂时。必要时用
DECIMAL(18,6)显式声明精度
最易被忽略的是权重归一化问题：业务上是否要求权重和必须为 1 或 100？SQL 计算本身不要求，但解释结果时若默认“权重即比例”，而实际存的是原始计数，就会引发误解。
