SUM()可直接累加负数，无需特殊处理；错误使用ABS或CASE会丢失零交易；需分方向统计时应采用条件聚合，如SUM(CASE WHEN amount>0 THEN amount ELSE 0 END)。
直接用 SUM() 就行，负数天然被正确累加
SQL 的 SUM() 函数对负数完全无感——它只是把所有非 NULL 值相加，正负号原样参与运算。你不需要做任何特殊转换或包裹逻辑，只要字段类型是数值型（如 DECIMAL、INT、FLOAT），SUM(net_amount) 就能准确得出净额总和。
常见错误现象：有人看到净额有负值，下意识写成 SUM(ABS(net_amount)) 或加 CASE WHEN net_amount ，结果算出来是“绝对值总和”或“只加正数”，完全偏离业务含义（比如退货冲减、退款、折扣都该拉低总净额）。
- 确保源字段不含意外的
NULL：如果net_amount允许为空，而你希望空值按 0 参与计算，得显式写成SUM(COALESCE(net_amount, 0)) - 注意数据类型溢出风险：大额负数 + 大额正数反复叠加时，
INT可能溢出；生产环境建议用DECIMAL(p,s)明确精度 - 聚合前过滤比聚合后处理更安全：比如只统计“已确认”状态的净额，应在
WHERE status = 'confirmed'中过滤，而不是在HAVING里筛SUM()结果
遇到 NULL 导致整组 SUM 为 NULL 怎么办？
SUM() 对空组（即没有匹配行）返回 NULL，不是 0。这在报表中常导致前端显示异常或计算中断。
典型场景：查某天某门店的净额总和，但当天没交易，SUM(net_amount) 返回 NULL，而非预期的 0。
- 用
COALESCE(SUM(net_amount), 0)是最常用且推荐的做法 - 避免用
ISNULL(SUM(net_amount), 0)（SQL Server 专属），降低跨数据库迁移成本 - 不要依赖
GROUP BY后加HAVING COUNT(*) > 0来规避——这会直接丢掉空组，无法体现“零交易”事实
需要分方向统计（收入/支出）再算净额？别在 SUM 里硬拆
如果原始表只有单字段 amount（正为收入、负为支出），而你想同时知道总收入、总支出、净额，别试图在一个 SUM() 里做条件判断来“模拟拆分”。
正确做法是用条件聚合，一次扫描完成三重计算：
SELECT SUM(CASE WHEN amount > 0 THEN amount ELSE 0 END) AS total_income, SUM(CASE WHEN amount < 0 THEN ABS(amount) ELSE 0 END) AS total_expense, SUM(amount) AS net_amount FROM transactions;
-
SUM(amount)仍是核心净额，无需额外逻辑 - 支出用
ABS(amount)是为了得到正数口径的“支出总额”，不是为了修正SUM() - 避免写成
SUM(CASE WHEN amount 再取反——语义不清，且负号容易漏
GROUP BY 后净额为 0 却没结果？检查 WHERE 条件是否误滤了 0 值
一个隐蔽但高频的问题：你写了 WHERE net_amount != 0，然后对结果 GROUP BY day 并 SUM(net_amount)，却发现某些本该有“正负相抵=0”的日期完全不出现在结果里。
这是因为 WHERE 在聚合前执行，所有 net_amount = 0 的原始行已被过滤，后续 SUM() 根本看不到它们，自然也不会产生“0”的分组结果。
- 若业务需要展示“当日净额为 0”的记录，必须移除
WHERE net_amount != 0，改用HAVING SUM(net_amount) != 0（放在GROUP BY后） - 或者，先用子查询/CTE 算出每日
SUM()，再对外层结果筛选，确保“0”不丢失 - 尤其注意：金额字段上建索引时，
!= 0条件通常无法高效走索引，可能拖慢全表扫描
