直接用 GROUP BY + SUM() 无法实现加权汇总，因为 SUM() 仅做简单累加，不处理权重计算；必须先逐行计算 sales × weight，再分组求和，即“先计算、后聚合”。
为什么直接用 GROUP BY + SUM() 无法实现加权汇总
因为 SUM() 只对数值列做简单累加，它不关心“这个值该占多大比重”。比如你有一组订单数据，想按地区统计“加权销售额”（销售额 × 客户等级权重），GROUP BY region; SUM(sales) 会丢掉权重信息——它压根不知道要乘什么。
真正需要的是：先算每行的加权值，再对结果分组求和。这不是聚合函数能一步完成的事，而是“先计算、后聚合”的两步逻辑。
标准写法：在 SELECT 中先做乘法，再用 SUM() 聚合
核心思路是把权重计算下沉到每一行，让聚合作用在已加权的结果上。常见错误是试图在 SUM() 里嵌套条件判断却忘了括号优先级，或误用 AVG() 替代加权和。
-
SUM(sales * weight)是最直接安全的方式，适用于权重为数值列的情况 - 如果权重来自映射表（如等级 → 权重），必须先
JOIN或用CASE WHEN转换，不能直接SUM(sales * CASE ...)却漏写ELSE 1导致 NULL 中断整个求和 - 注意
NULL传播：任一操作数为NULL，乘法结果即NULL，会被SUM()忽略——这有时是预期行为，有时是隐患
SELECT region, SUM(sales * COALESCE(weight, 1)) AS weighted_sales FROM orders o LEFT JOIN weights w ON o.level = w.level GROUP BY region;
当权重是动态规则（如按时间衰减）时怎么处理
比如“近7天订单权重为1.5，其余为0.8”，这种逻辑不适合塞进 JOIN 表，应该用表达式直写。关键点在于：规则越复杂，越要提前在子查询或 CTE 里算好加权值，避免在 GROUP BY 外层重复计算。
- 用
CASE WHEN写权重表达式时，务必确保所有分支返回同类型数值，否则可能触发隐式转换错误 - 日期比较别用
date >= '2024-01-01'这类硬编码，换成date >= CURRENT_DATE - INTERVAL '7 days'更可维护 - 如果权重依赖窗口函数（如按用户累计消费排名定权重），就不能在普通
GROUP BY里直接用——得先用 CTE 算出每行权重，再聚合
容易被忽略的精度与性能问题
加权汇总看似简单，但乘法会放大原始数据的精度误差。比如 sales 是 DECIMAL(10,2)，权重是 FLOAT，结果可能意外丢失小数位；而大表上对高基数列（如 user_id）做加权聚合，若没在 weight 列建索引，JOIN 阶段就可能拖慢整体速度。
- 显式声明结果精度：
SUM(CAST(sales * weight AS DECIMAL(15,4))) - 确认权重来源是否可下推：如果权重来自子查询，检查执行计划里是否有
Materialize节点；能改JOIN就别用相关子查询 - 测试
NULL权重的真实影响：有些业务要求权重为NULL的行不参与汇总，有些则需默认为 1——COALESCE()放哪一层，决定了语义
权重不是标量修饰符，它是参与计算的变量；只要它会变、会空、会跨表、会带单位，就得把它当成第一等公民来处理，而不是塞进聚合函数的括号里图省事。
