加权平均计算结果错误的主因是NULL值传播和整数除法截断，需用WHERE过滤空值、CAST转浮点防截断、NULLIF防除零，并确保分组粒度正确及权重用DECIMAL存储保精度。
为什么直接用 SUM(权重 * 值) / SUM(权重) 有时结果不对
常见现象是结果为 NULL 或整数截断（比如明明该是 87.6，却显示 87）。根本原因有两个：一是某行的 权重 或 值 为 NULL，导致整行参与计算时整个乘积变 NULL；二是数据库默认做整数除法（尤其在 PostgreSQL、SQL Server 中，当两个 INT 相除，结果仍为 INT）。
实操建议：
- 务必用
WHERE 权重 IS NOT NULL AND 值 IS NOT NULL过滤掉空值行，不能只依赖SUM()自动忽略——它虽会跳过NULL，但权重 * 值若任一为NULL就得全盘失效 - 强制类型提升：把分子或分母转为浮点，例如写成
SUM(CAST(权重 AS DECIMAL(10,2)) * 值) / SUM(CAST(权重 AS DECIMAL(10,2)))，或更简洁地用1.0 * SUM(权重 * 值) / SUM(权重) - MySQL 用户可直接用
AVG()的加权变体？不行——AVG()本身不支持权重，必须手写公式
PostgreSQL 和 SQL Server 中除零错误怎么防
SUM(权重) 为 0 时，除法会报错（PostgreSQL 报 division by zero，SQL Server 报 Divide by zero error），而 MySQL 默认返回 NULL（取决于 sql_mode）。这不是边缘情况——比如按类别分组时，某类恰好没数据，SUM(权重) 就是 0。
实操建议：
- 用
NULLIF(SUM(权重), 0)替代裸SUM(权重)，让分母为 0 时变NULL，整个表达式结果自然为NULL（安全且符合语义） - 如果需要返回 0 而非
NULL，套一层COALESCE(..., 0)，但要清楚：0 可能掩盖真实无数据问题 - 不要用
CASE WHEN SUM(权重) = 0 THEN 0 ELSE ... END—— 因为SUM(权重) = 0在没有匹配行时是NULL，不是0，条件判断会失效
GROUP BY 场景下权重列要不要加进 SELECT
当你按 课程 分组算各科加权平均分，权重来自 学分，值来自 成绩。这时候如果在 SELECT 里多写了个 学分，多数数据库（如 MySQL 5.7+ 严格模式、PostgreSQL）会直接报错：column "学分" must appear in the GROUP BY clause or be used in an aggregate function。
实操建议：
-
学分是明细列，不是聚合列，不能出现在SELECT中（除非套MAX(学分)等聚合，但通常无意义） - 真正要检查的是：分组键是否覆盖了所有影响权重逻辑的维度。例如，同一门课不同班级的学分可能不同，那就得按
课程, 班级联合分组，否则权重会被错误合并 - 别依赖“看起来权重都一样”就省略分组字段——数据一致性比直觉更可靠
性能和精度：用 DECIMAL 还是 FLOAT 存权重
金融、教育评分等场景对精度敏感。用 FLOAT 存学分或权重，可能导致 SUM(权重) 出现微小误差（如 3.0 存成 2.999999999），进而让最终加权平均偏差 0.01 分以上。
实操建议：
- 权重列优先定义为
DECIMAL(p,s)，例如学分 DECIMAL(3,1)（支持 0.0–99.9） - 避免在计算中隐式转
FLOAT：像1.0 * ...在某些数据库里会触发 float 运算，改用CAST(... AS DECIMAL(12,4))更可控 - 大数据量时，
SUM()本身很快，瓶颈常在过滤和分组；确保(分组字段, 权重, 值)上有复合索引（如CREATE INDEX idx_grade ON 成绩表(课程, 学分, 成绩)）
加权平均看着只是一行公式，但空值、除零、类型隐式转换、分组粒度、数值精度——每个点漏掉一个，结果就可能离谱。尤其是生产环境里，权重字段常来自用户输入或上游系统，不能假设它“应该”干净。
