ABS()直接返回数值绝对值，用于差额计算可省去CASE判断；需确保输入为数值型，NULL应先用COALESCE处理，主流数据库均支持但空值、类型转换和浮点精度行为略有差异。
ABS函数在差额计算中的基本用法
SQL里的ABS()直接返回数值的绝对值，不改变数据类型，也不需要额外判断正负——这正是处理业务差额（比如实际值 vs 预算值、今日销量 vs 昨日销量）时最省心的一环。
常见错误是先用CASE WHEN做正负判断再取值，纯属多此一举；ABS(actual - budget)一行就能替代四五行逻辑。
- 参数必须是数值型：如果字段是字符串（如
'123.45'），需先用CAST()或CONVERT()转成DECIMAL或FLOAT，否则多数数据库会报错Invalid argument to ABS() - NULL参与运算结果仍是NULL：若
actual或budget可能为空，得提前用COALESCE(actual, 0)兜底，否则整行差额会消失 - 浮点数精度问题在ABS里不放大也不缓解：比如
ABS(0.1 + 0.2 - 0.3)在某些数据库中仍可能返回5.5511e-17，不是ABS的问题，而是底层浮点表示导致的
不同数据库对ABS的兼容性差异
所有主流SQL引擎都支持ABS()，但行为细节有差别：
- MySQL和PostgreSQL：支持任意数值类型，包括
TINYINT、NUMERIC(p,s)，返回类型与输入一致 - SQL Server：对
INT输入返回INT，但对DECIMAL输入可能提升精度（如DECIMAL(5,2)→DECIMAL(6,2)），若后续做SUM聚合，列定义不匹配可能引发隐式转换警告 - SQLite：把非数字字符串转成0再取绝对值（比如
ABS('abc')= 0），容易掩盖数据清洗问题，生产环境务必前置校验
结合GROUP BY统计平均绝对偏差（MAD）
业务中常需看某类商品/区域的平均偏差程度，这时候不能只写AVG(ABS(diff))就完事——得确认是否已排除异常离群值，否则一个超大差额会拉高整体MAD。
- 先过滤掉明显无效差额：例如
WHERE ABS(actual - budget) < 1000000（根据业务设定合理阈值） - 避免双重嵌套写法：
AVG(ABS(COALESCE(actual,0) - COALESCE(budget,0)))比子查询更高效，执行计划通常少一层临时表 - 注意空组：如果某分组内所有
actual和budget全为NULL，AVG()返回NULL而非0，前端展示时需单独处理
ABS和窗口函数搭配计算滚动偏差
要查“每个销售员最近3笔订单的实际值与目标值偏差的绝对值中位数”，就得用ABS()配合窗口函数，但顺序不能错。
- 必须先用
ABS(actual - target)算出每行偏差，再进PERCENTILE_CONT(0.5) OVER (PARTITION BY sales_id ORDER BY order_date ROWS BETWEEN 2 PRECEDING AND CURRENT ROW)——反过来（先窗口后ABS）语法不合法 - PostgreSQL支持在窗口帧内直接调用
ABS，但MySQL 8.0+要求ABS作为计算列出现在SELECT列表中，不能藏在窗口函数内部表达式里 - 性能敏感场景下，避免在ORDER BY里用
ABS()：比如ORDER BY ABS(score - baseline)会导致无法使用索引，应提前物化该字段
真正麻烦的从来不是ABS()本身，而是差额来源字段的空值、类型混杂、单位不统一（比如有的预算存的是万元，有的是元）。函数再简单，输进去的是脏数据，出来的绝对值照样没业务意义。
