直接用SUM(SIGN(amount))不能算金额差额，因其仅统计符号个数之差（正数个数减负数个数），而非正负金额本身的代数和；正确做法是分别求正数和负数金额和再相减。
为什么直接用 SUM(SIGN(amount)) 不能算差额？
很多人看到 SIGN() 返回 -1/0/1，就以为 SUM(SIGN(amount)) 能得出“正账单比负账单多几张”，但这是计数，不是金额差额。真正要的是：所有正数 amount 加起来，减去所有负数 amount 的绝对值——也就是 SUM(CASE WHEN amount > 0 THEN amount ELSE 0 END) - SUM(CASE WHEN amount 。而 <code>SIGN() 在这里只是个“符号提取器”，必须配合原值才能还原金额方向。
SIGN() 和 amount 相乘才是关键一步
SIGN(amount) 本身不保留数值大小，但 amount * SIGN(amount) 恒等于 ABS(amount)，没用；真正有用的是 amount * SIGN(amount) 这个组合本身——等等，不对，再想：其实 amount 已经自带符号了。所以最简方式是直接 SUM(amount)？那为什么还要提 SIGN？因为需求常带条件：比如“只统计已核销的正负账单差额”，这时 SIGN 可用于过滤或分组。更典型的用法是：SUM(amount * SIGN(amount)) 等价于 SUM(ABS(amount))，而 SUM(amount) 才是净差额。所以别绕远——SIGN 在差额统计里，主要价值在辅助条件判断，而非直接参与求和。
-
SUM(amount)直接给出净差额（推荐首选） - 需要按符号分别看时，用
SUM(CASE WHEN SIGN(amount) = 1 THEN amount ELSE 0 END)提取正向总和 -
SIGN(amount) = -1可安全用于WHERE或CASE，比amount 少一次比较运算（但优化微乎其微） - 注意：SQL Server 中
SIGN(NULL)返回NULL，会拖累整个SUM结果为NULL，务必加WHERE amount IS NOT NULL
MySQL / PostgreSQL / SQL Server 对 SIGN 的行为差异
三者都支持 SIGN(x)，但边界情况处理略有不同：
- 输入
0：全部返回0，一致 - 输入
NULL：MySQL 和 PostgreSQL 返回NULL；SQL Server 也返回NULL，无差异 - 浮点精度：PostgreSQL 对
SIGN(0.0)和SIGN(-0.0)区分（后者返回 -1），MySQL 和 SQL Server 均不区分，统一为 0——如果账单金额来自 IEEE 754 计算且含负零，这点可能引发偏差 - 性能上无显著区别，但 PostgreSQL 允许在索引表达式中使用
SIGN(amount)，可用于加速按正负分类的查询
真实场景中的错误写法与修复
常见翻车现场：
- 写成
SUM(SIGN(amount))→ 得到的是“正账单张数减负账单张数”，不是金额差，修复：改用SUM(amount) - 写成
SUM(amount * SIGN(amount))→ 实际算的是SUM(ABS(amount))，即总额度，不是差额，修复：删掉* SIGN(amount) - 忽略空值：语句没加
WHERE amount IS NOT NULL，导致整列SUM为NULL，修复：显式过滤或用COALESCE(SUM(amount), 0) - 在
GROUP BY中误用SIGN：比如GROUP BY SIGN(amount)后再SUM(amount)，这能分组出正/负/零三类，但若只想看整体差额，这步纯属多余
最简、最稳、最不易错的做法，就是忘记 SIGN，直接写 SUM(amount)。只有当你需要按符号切片分析时，SIGN 才真正派上用场——它是个分类工具，不是求和组件。
