sql中无原生加权分组，需在sum()内用case when将权重映射为数值后累加；必须写在sum内部、覆盖所有分支（含else 0）、保持类型一致，并手动计算加权平均的分子分母。
GROUP BY 配合 CASE WHEN 实现自定义权重加权求和
直接用 SUM() 对带权重的字段做计算，核心是把权重逻辑塞进聚合表达式里，而不是先加权再分组。常见错误是试图在 WHERE 或外部查询里处理权重，结果要么过滤掉数据，要么无法按组归集。
典型场景：销售表里不同产品线利润率不同（如 A 类 15%，B 类 8%，C 类 12%），要按区域统计加权销售额总和。
- 权重必须写在
SUM()内部，例如SUM(amount * CASE WHEN product_type = 'A' THEN 0.15 WHEN product_type = 'B' THEN 0.08 ELSE 0.12 END) - 不能写成
SUM(amount) * 0.15——这会把整组的 sum 统一乘一个数，失去按行加权的意义 -
CASE WHEN的ELSE分支建议显式写出，避免 NULL 导致整行加权项为 NULL，拖垮整组结果
用 JOIN 关联权重表时注意 NULL 和重复匹配
当权重存在独立配置表（比如 weight_config 表含 product_type 和 weight 字段），用 JOIN 引入权重比硬编码更灵活，但容易出错。
常见错误现象：SUM() 结果翻倍、部分组结果为 NULL、某些 product_type 完全消失。
- 必须用
LEFT JOIN，否则缺失权重配置的产品会被整个排除 - JOIN 条件要严格对齐，比如
ON t.product_type = w.product_type，别漏掉AND w.effective_date 这类时效条件 - 加权计算时包裹
COALESCE(w.weight, 0)，防止 NULL 权重让amount * NULL得到 NULL，进而使整组SUM()为 NULL
MySQL 8.0+ 可用 WINDOW 函数做组内加权占比，但 GROUP BY 仍是基础
如果需求不是单纯求和，而是“每个区域内各产品线加权贡献占比”，有人会想用 SUM() OVER (PARTITION BY region)。但注意：窗口函数不替代 GROUP BY，它是在已分组结果上再算相对值。
典型误用：在没 GROUP BY 的情况下直接写 SUM(amount * weight) OVER (PARTITION BY region)——这会返回原始行数，不是每组一行。
- 正确做法是先
GROUP BY region, product_type算出各组加权和，再套一层查询用窗口函数算占比 - 或者用 CTE 拆开：第一层
GROUP BY得基础加权和，第二层用SUM(...) OVER (PARTITION BY region)算分母 - MySQL 5.7 不支持窗口函数，强行用会报错
ERROR 3577: Window function is not allowed in this context
PostgreSQL 中 array_agg + unnest 可实现动态权重列表，但性能代价明显
极少数场景需要一组记录对应多个权重（比如一条订单含 3 个 SKU，每个 SKU 有独立营销系数），这时硬写 CASE WHEN 不现实。PostgreSQL 可用数组展开方式处理，但别轻易用。
容易踩的坑：查询变慢、执行计划不可控、JOIN 膨胀后 SUM() 算错。
- 必须确保权重数组与主表字段一一对应，常用
array_position()或UNNEST(... WITH ORDINALITY)对齐顺序 - 加权计算前加
WHERE weight_arr IS NOT NULL AND cardinality(weight_arr) > 0，避免空数组炸开成零行 - 这种写法在数据量超 1 万行时，
UNNEST带来的中间行膨胀会让SUM()变慢 3–5 倍，优先考虑预处理成宽表
实际业务中，90% 的加权求和用 CASE WHEN 写死权重就足够了；权重表方案适合配置频繁变更的系统；数组方案只在遗留数据结构无法重构时兜底。权重逻辑越靠近数据源头（比如写入时就存加权值），后续查询越简单稳定。
