直接用SUM()求含负数字段的和得到代数和，但业务需分开统计正负数和；应使用CASE WHEN拆解，如SUM(CASE WHEN credit_num>0 THEN credit_num ELSE 0 END)，并确保命名清晰区分语义。
直接用 SUM() 对含负数的字段求和，结果就是代数和——正负抵消后剩一个净值。但业务上常需要“正数总和”“负数总和”分开看，比如统计加减分、收入支出、申购赎回。这不是数据清洗问题，是聚合逻辑本身要拆解。
用 CASE WHEN 区分正负再 SUM
这是最通用、兼容性最强的做法，所有主流 SQL 引擎（MySQL 5.7+、PostgreSQL、SQL Server、Oracle）都支持。
-
SUM(CASE WHEN credit_num > 0 THEN credit_num ELSE 0 END)得正数累加，负数和 0 被转为 0 不参与 SUM(CASE WHEN credit_num 得负数累加，正数和 0 同样被过滤- 注意：不要写成
WHERE credit_num 后再 <code>SUM()——那样会丢掉同组内其他正数行，破坏分组完整性 - 如果字段可能为 NULL，建议补
COALESCE(credit_num, 0)避免整行被忽略
ABS 函数只适用于“取绝对值总和”，不是“负数总和”
看到知识库里有 SUM(ABS(credit_num))，这容易误解：它算的是所有数值的绝对值之和，即把 -5 和 +3 都当 5 和 3 加起来得 8，而非“负数合计 = -5”。这在统计“扣分总次数”或“操作量级”时有用，但不等于负数本身的代数和。
- 真正要负数合计，必须保留符号，不能用
ABS包裹整个字段 -
ABS只应在CASE内部用于构造新值，比如“减分数”想显示为正数：SUM(ABS(CASE WHEN credit_num - 滥用
ABS会导致财务类报表出现方向性错误，比如退款总额变成正向流入
GROUP BY 后再累加正负和？窗口函数才是正解
如果已经按用户、月份等分组聚合出每行的净变化值（如 net_change），还想看“该用户累计正变动”“该用户累计负变动”，就不能再套一层 GROUP BY ——那会再次压缩行。必须用窗口函数。
SUM(CASE WHEN net_change > 0 THEN net_change ELSE 0 END) OVER (PARTITION BY user_id ORDER BY create_time)- 漏掉
ORDER BY会变成每个用户的固定总和，不是逐行累加 - MySQL 8.0+、PostgreSQL、SQL Server 支持；MySQL 5.7 及更早需用子查询模拟
- 排序字段若含 NULL，
ORDER BY COALESCE(create_time, '1970-01-01')更安全
真正容易被忽略的点是：正负拆解不是纯语法问题，而是语义建模选择。同一列上同时跑“正数和”“负数和”“绝对值和”，三者物理意义完全不同，命名必须清晰（如 income_sum、refund_sum、abs_amount_sum），否则下游取数时极易用错。
