结论：分组中负数累加本身无问题，SUM(col)天然支持负数；真正错误是混淆不同业务意图——绝对值之和须用SUM(ABS(col))，正负分别求和须用CASE WHEN。
直接说结论：分组中负数累加本身没有问题，SUM(col)天然支持负数；真正出错的，是把“绝对值之和”“正负分别求和”“负数归零计入”这些不同业务意图，全写成同一个 SUM(col)。
分组求绝对值之和必须用 SUM(ABS(col))，不是 ABS(SUM(col))
比如统计每类交易的“发生总额”（不区分收入支出），你想要的是所有金额的绝对值加总，不是净额的绝对值。前者反映业务活跃度，后者可能掩盖大额正负冲销。
-
SUM(ABS(transaction_amount))：对每行先取绝对值，再按分组加总 → 正确 -
ABS(SUM(transaction_amount))：先按分组算净额，再取绝对值 → 错误场景常见于“误以为这是总量” - NULL 值在
ABS(NULL)后仍是 NULL，SUM()自动跳过，无需额外处理 - MySQL、PostgreSQL、SQL Server、Oracle 全部原生支持
ABS()，无兼容性风险
要分开统计正数和负数的和，用 CASE WHEN 套 SUM()
财务对账、风控分析常需拆开看：收入多少、退款多少、净变动多少。这时不能依赖 ABS()，必须显式分支。
- 正数和：
SUM(CASE WHEN amount > 0 THEN amount ELSE 0 END) - 负数和：
SUM(CASE WHEN amount （注意保留负号） - 避免漏掉 0 值：显式写
ELSE 0，而不是省略，否则整行会被SUM()忽略 - 若字段含 NULL，
CASE WHEN中未覆盖 NULL 分支时，结果为 NULL；建议补上WHEN amount IS NULL THEN 0或确保上游已清洗
GROUP BY 里别对数值字段用 ABS()
这不是语法错误，但极易引发逻辑 bug。例如按用户 ID 分组，却写成 GROUP BY ABS(user_id)，会导致 user_id = -100 和 100 被合并成一组 —— 这几乎从来不是本意。
- 分组依据应保持业务语义清晰：
GROUP BY user_id，不是GROUP BY ABS(user_id) - 数值转换（如取绝对值、截断、四舍五入）只应在聚合表达式内部做，比如
SUM(ABS(amount)) - 若真需要按“ID 绝对值”分组（极少见），务必确认业务规则，并在注释中明确说明原因
最易被忽略的一点：SUM(ABS(col)) 和 SUM(col) 在执行计划上几乎没有性能差异，瓶颈永远在 I/O 和分组基数，不在 ABS() 计算本身。但一旦把 ABS() 错放到 GROUP BY 或 WHERE 中，就可能让索引失效、触发全表扫描——这种错误不会报错，只会悄悄拖慢查询。
