分组求和时负数被误当成正数加总，本质是需求理解偏差：若需绝对值之和，必须用sum(abs(col))；若仅对原始值求和，直接sum(col)即可。abs()须作用于列而非sum外，各主流数据库均支持，null自动被忽略。
分组求和时负数被误当成正数加总？先确认业务意图
SQL里SUM()对负数本身完全正常，问题往往出在需求理解偏差：你是不是其实想“把所有值当正数加总”（即求绝对值之和），而不是“对带符号的原始值求和”？如果是后者，SUM(col)直接写就完事；但前者必须显式用ABS()，否则负数会拉低总和，结果明显偏小。
用ABS()实现分组内绝对值求和
这是最常见也最稳妥的做法，适用于“统计变动总量”“计算误差绝对累计”等场景。注意ABS()必须套在列上，不能套在SUM()外——SUM(ABS(col))是对每个值先取绝对值再加总；而ABS(SUM(col))是先加总再取绝对值，二者数学意义完全不同。
-
SUM(ABS(transaction_amount))→ 每笔交易都算作正向发生额累加 -
ABS(SUM(transaction_amount))→ 整个分组净余额的绝对值（可能掩盖大幅正负抵消） - MySQL、PostgreSQL、SQL Server、Oracle 均支持
ABS()，无兼容性问题 - 如果
col含NULL，ABS(NULL)仍为NULL，会被SUM()自动忽略（符合预期）
需要条件化处理负数？用CASE WHEN替代ABS()
当逻辑不是简单“全转正”，而是比如“负数按0计入，正数照常加”，或“负数翻倍计入”，就不能依赖ABS()了，得用分支表达式。此时CASE WHEN更灵活，也更易读。
- 把负数当0处理：
SUM(CASE WHEN score - 负数取反后加总（等价于
ABS()）：SUM(CASE WHEN col - 避免在
CASE里写ELSE NULL，否则SUM()会跳过整行——明确写ELSE 0更安全 - 某些旧版SQLite不支持
CASE嵌套在聚合函数里，需查证版本；主流数据库无此限制
性能与可读性提醒：别在GROUP BY字段上滥用ABS()
如果误把ABS(user_id)放进GROUP BY，会导致ID为-100和100的用户被合并在同一组——这通常不是本意，而是疏忽。分组依据应保持业务语义清晰，数值转换只应在聚合表达式内部做。
另外，对大表执行SUM(ABS(col))不会比SUM(col)慢多少，因为ABS()是标量函数，计算开销极低；真正影响性能的是是否走索引、数据量大小和分组维度基数。
