SQL中无原生加权分组，需用CASE在SUM内将权重映射为数值后累加；必须写在SUM内部、覆盖所有分支（含ELSE 0）、保持类型一致，并手动计算加权平均的分子分母。
用 CASE 配合 SUM 实现加权分组统计
直接说结论：SQL 里没有“按权重分组”这个原生操作，但用 CASE 把权重逻辑转成数值，再套 SUM 就能达成效果。本质是把“分类打分”变成“数值累加”，不是真在分组维度上加权，而是在聚合值上加权。
常见错误是试图在 GROUP BY 里塞权重表达式，或者误以为 AVG(weighted_column) 能自动按权重算——它不会，AVG 对所有行一视同仁。
- 权重必须提前映射为具体数字（比如等级 A→3、B→2、C→1），不能留空或用字符串参与计算
-
CASE必须写在SUM()内部，而不是外面包一层；否则分组后每组只出一个值，无法累计 - 如果某组没匹配到
CASE的任何条件，默认返回NULL，会让整行SUM结果变NULL，记得加ELSE 0
CASE 权重映射的写法细节
权重映射是否严谨，直接决定结果对不对。别图省事写 CASE WHEN score > 90 THEN 5 这种浮动逻辑——它算的是“符合条件的记录数”，不是“按记录权重加总”。要加权，就得让每行贡献自己的权重值。
典型场景：用户订单按等级打折，VIP 订单权重为 2，普通为 1，想算各城市加权订单量。
SELECT city,
SUM(CASE
WHEN level = 'VIP' THEN 2
WHEN level = 'PREMIUM' THEN 1.5
ELSE 1
END) AS weighted_order_count
FROM orders
GROUP BY city;- 所有分支必须同类型（全整数 / 全浮点），混合会导致隐式转换异常或截断（比如
1和1.5混用，某些数据库会统一转成DECIMAL，但精度可能意外丢失） -
ELSE分支不能省略，否则无匹配时该行权重为NULL，整个SUM变NULL - 字符串比较注意大小写和空格：
level = 'vip'在多数库不匹配'VIP'，建议统一用大写或加UPPER()
和 AVG、WEIGHTED_AVERAGE 的区别在哪
有些数据库（如 PostgreSQL 9.4+）支持 AVG(x) FILTER (WHERE ...)，但那只是条件平均，不是加权平均。真要算加权平均（比如各科成绩×学分），得自己手写分子分母：
SELECT dept,
SUM(score * credit) / NULLIF(SUM(credit), 0) AS weighted_avg_score
FROM courses
GROUP BY dept;- 分母用
NULLIF(SUM(credit), 0)是防除零，比CASE WHEN SUM(credit) = 0 THEN NULL ELSE ... END更简洁 - 别用
AVG(score * credit)—— 它算的是“每门课得分×学分”的平均值，不是“按学分加权后的成绩平均值” - MySQL 8.0+ 有窗口函数可辅助，但标准聚合仍需手动拆分子分母；SQLite 不支持
FILTER，只能靠CASE + SUM
性能与 NULL 处理的隐蔽坑
CASE 本身开销极小，但若嵌套过深（比如 10 层 WHEN）或字段无索引，配合大表 GROUP BY 时可能拖慢。更常被忽略的是 NULL 对聚合的污染。
- 只要
CASE输出列含一个NULL，SUM仍能正常算其他非空值（SQL 标准行为），但COUNT、AVG会跳过NULL行——这点容易误判结果偏小 - 如果原始字段（如
level）本身有NULL，且你没在CASE里显式处理，它就掉进ELSE分支；若漏写ELSE，整行权重变NULL，导致该行完全不参与SUM - 测试时务必用含
NULL和边界值的数据查一遍，比如插入一条level IS NULL的记录，看加权结果是否突降
权重逻辑越靠近业务规则，就越容易随需求变化而改错一行 CASE 就全偏了。上线前最好拿手工算的小样本对一遍结果。
