<p>ABS函数仅将数值转为非负数，不保留偏差方向；需先计算actual_amount - expected_amount得到带符号差值，再用ABS提取绝对值，且减法必须在ABS内部完成。</p>
ABS函数在账单差异计算中的真实作用
ABS 本身不区分正负偏差，它只做一件事：把任何数字变成非负数。账单差异的“正负偏差”需要你先算出原始差值（比如 actual_amount - expected_amount），再用 ABS 提取其绝对大小。很多人误以为 ABS 能保留符号信息或自动分类偏差方向，其实不能——它一视同仁地抹掉负号。
怎么写SQL才能同时看到偏差方向和绝对值？
必须分两步：先算带符号的差值，再套一层 ABS。常见错误是只用 ABS 包裹单边字段（如 ABS(actual_amount)），这毫无意义，因为单个金额没有“偏差”可言。
正确写法示例：
SELECT invoice_id, actual_amount, expected_amount, actual_amount - expected_amount AS deviation, -- 正数=超支，负数=结余 ABS(actual_amount - expected_amount) AS abs_deviation FROM billing_records WHERE status = 'settled';
- 永远把减法放在
ABS()里面，而不是外面加条件或单独处理 - 如果要按偏差方向分组统计，用
CASE WHEN actual_amount - expected_amount > 0 THEN 'over'，别试图从ABS结果反推 - 注意 NULL 值：只要
actual_amount或expected_amount是 NULL，整个差值就是 NULL，ABS(NULL)还是 NULL——得提前用COALESCE处理
ABS在WHERE条件里过滤偏差大小时的陷阱
想查“偏差超过500元”的记录，直接写 WHERE ABS(actual_amount - expected_amount) > 500 是对的；但若混用逻辑，比如 WHERE ABS(actual_amount) - ABS(expected_amount) > 500，结果完全失真——这算的是两个绝对值之差，不是实际偏差。
- 所有涉及“差异”的计算，减法必须在
ABS内部完成 - 在索引友好性上，
ABS(col1 - col2) > N通常无法走索引，大数据量时考虑预计算列或物化视图 - PostgreSQL 和 MySQL 对
ABS的 NULL 处理一致，但 SQLite 会返回 0，跨数据库迁移时需验证
为什么有时候ABS结果看起来“不准”？
最常被忽略的是数据类型隐式转换。比如 expected_amount 是 DECIMAL(10,2)，而 actual_amount 是 FLOAT，差值可能带浮点误差，ABS(-0.0000001) 看似是 0，实则不是。肉眼难辨，但会影响 = 0 判断或分组精度。
- 统一用
DECIMAL类型存金额，避免浮点运算 - 若必须比较“是否无偏差”，别用
ABS(deviation) = 0，改用ABS(deviation) （根据业务精度定阈值） - 导出到 Excel 后再看
ABS结果变异常？大概率是 Excel 自动四舍五入显示，实际值仍精确——检查原始查询结果而非渲染后数值
实际业务中，偏差方向比绝对值更重要；ABS 只是帮你量化“差多少”，从不回答“差在哪边”。
