多条件权重计算本质是逐行加权合成再聚合，不能用avg()或sum(字段)×系数，因前者无视权重、后者丢失个体差异；必须用sum(score×w1 + duration×w2 + is_urgent×w3)实现行级加权求和。
多条件权重计算综合聚合得分，本质是把多个字段按业务规则加权后求和，再分组聚合；不能靠单个聚合函数一步到位，必须在 SUM() 内部完成每行的加权合成。
为什么不能直接用 AVG() 或 SUM(字段) + 权重系数？
因为 AVG() 对所有值一视同仁，SUM(field) 只做简单累加，两者都不感知“哪个字段该占多大比重”。比如你有 score（满分100）、duration（时长分钟）、is_urgent（布尔），想算“响应质量得分 = score×0.6 + duration×(-0.02) + is_urgent×5”，这个公式必须作用在每一行上，再对结果求和或平均——不是先 SUM(score) 再乘 0.6。
- 误写成
SUM(score) * 0.6 + SUM(duration) * -0.02：会把整组的总分统一缩放，失去个体差异 - 漏处理
is_urgent类型：MySQL 中布尔值可直接参与运算，但 PostgreSQL 需显式转为CASE WHEN is_urgent THEN 1 ELSE 0 END - 负权重（如
duration×(-0.02)）会拉低得分，要确认业务逻辑是否允许；部分数据库不报错但结果易被误解
CASE WHEN 与数值列混合加权的写法要点
当部分权重来自静态规则（如等级映射）、部分来自数值字段（如评分、时长）时，CASE WHEN 必须嵌套进乘法表达式内部，且所有分支返回相同类型数值。
- 错误示范：
SUM(score * CASE WHEN level = 'A' THEN 1.2 END) + SUM(duration * 0.01)——CASE缺ELSE，遇到非 A 级别数据整项变NULL，拖垮整组 - 正确写法：
SUM(score * COALESCE(CASE WHEN level = 'A' THEN 1.2 WHEN level = 'B' THEN 0.9 ELSE 0.6 END, 0.6)) - 数值字段参与计算前建议兜底：
SUM(COALESCE(score, 0) * 0.6)，避免NULL × 数值 = NULL导致整行被SUM()忽略 - 所有权重分支必须显式写出，不可依赖隐式默认；浮点数建议写
1.2而非1.20，防止某些引擎触发意外精度转换
从配置表 JOIN 拉取动态权重时的坑
当权重规则存在独立配置表（如 weight_rules 含 metric、weight_value、effective_date）时，JOIN 是必要手段，但极易出错。
- 必须用
LEFT JOIN，否则缺失配置的指标会被整行排除，而非按默认权重计算 -
ON条件要完整，例如：ON t.metric = w.metric AND w.effective_date ，漏掉时效判断会导致过期权重生效 - 权重字段必须
COALESCE(w.weight_value, 0)，否则任一NULL会让整行加权结果为NULL - 若配置表存在一对多（如同一
metric多条生效记录），需提前去重或加LIMIT 1子查询，否则SUM()结果翻倍
分组后加权平均 vs 综合得分：别混淆分子分母
如果最终要的是“每组的平均综合得分”，不是总和，得除以有效行数；但注意：这不是除以 COUNT(*)，而是除以实际参与加权计算的行数（即未被 NULL 排除的行）。
- 安全写法：
SUM(score * 0.6 + duration * -0.02 + COALESCE(is_urgent::int, 0) * 5) / NULLIF(COUNT(*), 0) - 更精确写法（排除
score为NULL的行）：SUM(...) / NULLIF(COUNT(CASE WHEN score IS NOT NULL THEN 1 END), 0) - 不要用
AVG(score * 0.6 + ...)：它等价于SUM(...) / COUNT(*)，但会把score为NULL的行计入分母（因AVG()自动跳过NULL分子，却仍计数），导致分母偏大 - 大表上多次
COUNT()和SUM()可能重复扫描，建议用 CTE 先算好加权值列，再聚合
最常被忽略的是权重类型一致性——比如一个字段是 DECIMAL(5,2)，另一个是 FLOAT，相加后可能隐式转为 FLOAT 导致小数位丢失；上线前务必用 CAST(... AS DECIMAL(10,4)) 显式控制精度。
