<p>加权平均必须用SUM(value * weight) / SUM(weight)，不能用AVG()；需配合GROUP BY，处理NULL和除零错误，并确保数值类型正确。</p>
GROUP BY 后不能直接用表达式做加权，必须显式写出计算逻辑
很多人写 SELECT dept, SUM(salary * weight) 时发现报错或结果不对，根本原因不是语法错，而是 weight 列没参与分组或未被正确关联。SQL 要求：所有非聚合字段（如 dept）必须出现在 GROUP BY 中；而加权项（如 salary * weight）属于衍生计算，必须包裹在聚合函数内，且依赖的列（salary、weight）都得是表中真实存在的字段。
常见错误现象：Unknown column 'weight' in field list 或 Expression #2 of SELECT list is not in GROUP BY clause，本质是字段来源不明确或分组维度缺失。
- 加权汇总必须基于原始明细行计算，不能先
GROUP BY再对结果乘系数 - 如果
weight存在另一张表（比如绩效系数表），需先JOIN再聚合，不能靠子查询“事后补” -
weight为 NULL 会导致整行加权结果为 NULL，建议用COALESCE(weight, 1)防断
加权求和：SUM(salary * COALESCE(weight, 1)) 是最简安全写法
业务场景如“按部门统计加权薪资总额”，其中 weight 表示岗位系数或绩效权重。直接写 SUM(salary * weight) 风险高，因为任意一个 weight 为 NULL，整条记录就失效。
实操建议：
- 始终用
COALESCE(weight, 1)替代裸weight，避免 NULL 传播 - 若权重来自关联表（如
emp_score），必须显式JOIN ... ON emp.id = score.emp_id，不能只在SELECT里引用别名 - MySQL 8.0+ 支持窗口函数，但加权汇总仍推荐用
GROUP BY+SUM()，更直观可控
示例：SELECT dept, SUM(salary * COALESCE(performance_weight, 1)) AS weighted_salary_sum FROM employee e JOIN emp_score s ON e.id = s.emp_id GROUP BY dept;
HAVING 无法过滤加权中间值，筛选必须前置到 WHERE 或 JOIN 条件
有人想写 HAVING SUM(salary * weight) > 100000，这语法合法，但逻辑危险——它是在分组后才筛，意味着低权重员工可能被错误保留，拉高分母。真正该筛的是原始数据质量。
关键判断：加权汇总的筛选条件，95% 应放在 WHERE 或 ON 里。
- 要排除试用期员工？加
WHERE status != 'probation'，别等聚合完再HAVING - 权重小于 0.5 的记录无效？写在
JOIN ... ON ... AND s.weight >= 0.5，而不是HAVING -
HAVING只适合筛聚合结果本身，比如“加权总和超阈值的部门”，而非“参与加权的原始行是否达标”
多级加权（如部门×职级）必须用复合 GROUP BY，别幻想单列分组能自动展开
当业务要求“每个部门下再按职级细分加权薪资”，有人会漏掉 job_level 到 GROUP BY，导致 MySQL 5.7+ 报错，或低版本静默合并（结果错得离谱）。
实操要点：
- 分组维度必须与输出列严格一致：
SELECT dept, job_level, SUM(salary * weight)→GROUP BY dept, job_level - 若某部门没有某个职级，不会自动补 0 行，需要
LEFT JOIN+COALESCE(SUM(...), 0) - 排序建议放最后：
ORDER BY dept, SUM(salary * weight) DESC，避免干扰分组逻辑
容易被忽略的一点：加权汇总的本质是逐行计算后归并，不是“先分组再乘系数”。任何试图跳过明细行、用视图或物化结果做二次加权的操作，都会丢失精度。
