sum()本身不会导致异常，其对负数的代数求和数学正确，但业务上常需区分充值、扣费、退款等不同语义指标，须用case when分流统计，而非where过滤或abs取值。
SUM() 本身不会导致异常——它只是忠实地做代数求和。所谓“业务逻辑的特殊异常”，其实是聚合结果与业务语义错位造成的误解或错误决策。
SUM() 对负数的计算是数学正确的，但业务上常不想要“净值”
SUM(credit_num) 得到的是净变化值，比如 +100（充值）、−30（扣费）、−50（退款） → 结果是 20。
但业务系统可能真正关心的是：
- 充值总额：100
- 扣费总额：−30
- 退款总额：−50
- 净变动：20
这四个指标语义完全不同。SUM() 只能给最后一个，其他三个必须靠条件分支显式构造。
常见错误现象：
- 财务对账时发现“收入”列显示为正数，实际是
SUM()把退款也混进去了 - 运营看“用户总操作量”，却用
SUM(amount)得到接近零的值，误判活跃度低 - 报表中“支出合计”字段显示为负数，前端直接渲染成 “−¥4,500”，而业务方要求统一显示正数带“支出”标签
分组内正负必须拆开统计？别用 WHERE 过滤后再 SUM()
这是最容易踩的坑：
❌ 错误写法：SELECT user_id, SUM(amount) FROM orders WHERE amount <br>
→ 它只保留负数行，<strong>丢掉了该用户所有正数订单</strong>，破坏了分组完整性（比如用户有 +200 和 −80，这条 SQL 只算 −80，漏掉 +200）
✅ 正确做法是用 CASE WHEN 在聚合内部分流：SUM(CASE WHEN amount > 0 THEN amount ELSE 0 END) AS income_sumSUM(CASE WHEN amount
一款AI工具，主要用于使用 Codex CLI 进行深度网络搜索，适用于需要多源综合分析的复杂查询。当 `web_search`（Brave）返回结果不足，或用户……时使用，适合需要提升相关任务效率的用户。
注意点：
-
ELSE 0比ELSE NULL更安全，避免整行被跳过（尤其当外层还有COALESCE()或计算衍生字段时） - 若字段可能为
NULL，建议先套COALESCE(amount, 0)，否则CASE判断会跳过该行 - 不要写成
SUM(ABS(amount))代替负数求和——它返回的是绝对值之和（如 −5 和 −3 变成 8），不是负数本身的代数和（应为 −8）
累计正/负变动？窗口函数才是分组后逐行累加的解法
如果已按用户+时间分组出每笔 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，结果就是每个用户的固定总和，不是随时间推进的累计值 -
PARTITION BY要和业务分组维度一致（如按user_id，而不是ABS(user_id)——后者会让负 ID 用户被错误合并）
真正容易被忽略的，是“负数要不要参与分组依据”这件事。
比如把 ABS(status_code) 放进 GROUP BY，会导致 status_code = −1 和 1 被归为同一组——这不是计算问题，是语义污染，且极难排查。
