<p>SUM(CASE WHEN ... THEN value * weight ELSE 0 END) 是安全的加权求和写法，必须写 ELSE 0、保持类型一致、避免深层嵌套，并优先用 JOIN 权重表替代硬编码 CASE。</p>
在 SUM() 里嵌套 CASE WHEN 是可行的，但不是“加权求和”的唯一或最优解
直接在 SUM() 内部写 CASE WHEN 能实现条件加权，比如按状态给不同系数：但容易误以为这是“加权求和”的标准写法。实际上，SUM(CASE WHEN ... THEN value * weight ELSE 0 END) 才是安全模式；若漏 ELSE 0，NULL 会把整组求和结果变 NULL。
- 必须用
ELSE 0（而非ELSE NULL），否则SUM()遇到任意 NULL 就返回 NULL - 所有
THEN分支返回值类型要一致：比如都返回DECIMAL，别混用INT和VARCHAR，否则隐式转字符串后SUM()失效 - 权重不能动态来自另一张表——
CASE WHEN是标量表达式，不支持子查询；真要查权重表，得先JOIN进来再CASE
WHERE 里不能写 CASE WHEN，但加权求和常被误放错位置
有人想“只对 VIP 用户加权”，于是写 WHERE CASE WHEN user_type = 'VIP' THEN score * 1.5 ELSE score END > 100——这在 PostgreSQL 可能语法通过，但语义错误：WHERE 是过滤行，不是计算列；且该写法让优化器无法走索引，性能陡降。
- 正确做法是把加权逻辑放在
SELECT或子查询里，再用外层WHERE过滤结果，例如：SELECT * FROM (SELECT id, score * CASE WHEN user_type = 'VIP' THEN 1.5 ELSE 1.0 END AS weighted_score FROM users) t WHERE weighted_score > 100 - MySQL 8.0+ 虽允许
WHERE (CASE WHEN ... THEN true END)，但执行计划常退化为全表扫描 - 如果权重依赖聚合结果（如“近 7 天平均订单额 > 500 的用户加权 1.2”），必须用 CTE 或子查询预计算，不能塞进
CASE里
嵌套 CASE WHEN 在 SUM 中易导致类型混乱和 NULL 泄漏
真实翻车现场：想对高价值订单加权 2 倍、中价值加权 1.2 倍、其他不加权，结果报表里加权和全是 0 或 NULL。问题往往出在嵌套层级和类型隐式转换上。
- 避免三层及以上嵌套：如
SUM(CASE WHEN a THEN CASE WHEN b THEN x * 2 ELSE x * 1.2 END ELSE x END)——可读性差，且内层CASE若某分支返回NULL，外层就继承 NULL - 显式转类型比依赖隐式转换更稳：用
CAST(... AS DECIMAL(10,2))包住每个THEN分支，尤其当原始字段是INT但权重是小数时 -
ELSE必须写，且值类型与THEN一致；宁可写ELSE 0.0也不写ELSE NULL
替代方案：用 JOIN + 显式权重表比硬编码 CASE 更可持续
当权重规则变多（比如按地区、时段、用户等级组合出 12 种系数），把所有 WHEN 条件堆在 SQL 里会失控。这时应把权重逻辑下沉到独立表。
- 建一张
weight_rules表，字段含region,user_tier,effective_date,multiplier -
JOIN后直接乘：SUM(t.amount * w.multiplier)，逻辑清晰，DBA 可审计，业务方也能自行维护权重 - 比嵌套
CASE更易测试：权重表可单独单元测试，SQL 主体只剩简单乘法和求和
最常被忽略的一点：加权求和的结果是否参与后续 GROUP BY 或窗口函数？如果在 OVER (PARTITION BY ...) 里用嵌套 CASE，务必确认每层 CASE 都覆盖了分区内的全部数据可能性，否则分组内部分行会被判为 NULL，拉低整体统计值。
