如果你经常在SQL里跟数值打交道，那么ABS函数你肯定不陌生。说白了，它的本职工作就是返回一个数值的绝对值，并且保持你给出这个数值的数据类型不变。它支持INT、FLOAT、DECIMAL这些常见的数值类型，但记好了，字符串和NULL它可不吃这一套——传入字符串在很多数据库里就是报错，传NULL就乖乖返回NULL。这个函数最常见的用法，就是在WHERE条件里帮我们判断一个数值距离中心值有多远。
ABS函数的基本用法和参数类型
ABS 本身就是SQL标准里的老面孔了，用法非常直白：你给它一个数值表达式（INT、FLOAT、DECIMAL，甚至带符号的 NUMERIC 都没问题），它就返回对应的绝对值，而且不改变原来的数据类型。但要注意，字符串或 NULL 是它的禁区——多数数据库碰到这种情况，要么直接报错，要么返回 NULL。
实际开发中，有些错误挺常见但也容易忽略。比如在MySQL里写 ABS('-5')，它没准能隐式转换过去，让你误以为没问题；可换到PostgreSQL或者SQL Server，立刻甩你一个 invalid input syntax for type numeric，毫不留情。还有，ABS(NULL) 永远返回 NULL，不是0，这在处理可能为空的列时要特别留个心眼。
这里有几个实用的写法建议：
- 推荐写法：
ABS(column_name)或ABS(-12.34)，确保你喂进去的是明确的数值型数据。 - 避免写法：
ABS(CAST(str_col AS INT))—— 先转换再取绝对值，听起来很周全，但可靠性不如在应用层把类型搞干净。 - SQL Server特别提醒：它对
ABS的输入类型检查很严格。比如碰到TINYINT类型的负数取绝对值，很容易溢出，因为TINYINT本身范围只有0到255，根本表示不了 -128 的绝对值。
在 WHERE 条件中用 ABS 过滤偏离中心值的数据
实际项目里，ABS 最经典的使用场景就是“距离判断”。比如说，你想查一下温度传感器里那些偏离平均值不超过 ±2 度的记录，或者找出测试结果误差在某个阈值内的数据。
举个例子就清楚了（MySQL/PostgreSQL通用）：
SELECT * FROM sensor_data WHERE ABS(temperature - 25.0) <= 2.0;
不过这里有个性能上的小坑需要留意：如果 temperature 列上建了索引，那么写成 ABS(temperature - 25.0) <= 2.0 ，数据库几乎没办法利用这个索引，因为表达式直接破坏了索引的有序性。更高效的做法是直接写成 temperature BETWEEN 23.0 AND 27.0，语义完全一样，但索引就能正常跑起来了。当然，如果你的计算逻辑真的特别复杂，比如涉及多列组合的偏差判断，那 ABS 该用还是得用，这个取舍要自己把握。
ABS 和负号连用时的常见陷阱
不少开发者会写 -ABS(x) 想实现“取反”的效果，但操作一不注意就容易理解偏——它并不是让负数变正、正数变负，而是固定返回一个非正值。更隐蔽的问题是，嵌套使用时优先级搞混的人也不少。
ABS(-x)和ABS(x)其实完全等价，没必要多套一层负号给自己添麻烦。ABS(x) * -1等同于-ABS(x)，结果永远是 ≤ 0 的。如果你真想翻转符号，需要写CASE WHEN x > 0 THEN -x ELSE ABS(x) END。- 在
ORDER BY里写ORDER BY ABS(score)，结果会按绝对值升序排列，但原始的正负信息也就跟着丢了，后面想区分 +100 和 −100 就没那么容易了。
不同数据库对 ABS 的兼容性细节
虽然绝大多数SQL方言都支持 ABS，但在边界行为上，它们之间还是有一些微妙差异的：
- MySQL：支持
ABS(TIME_TO_SEC(...))这样把时间转成数值再取绝对值，但说实话，这种做法不太可靠，建议别依赖它。 - PostgreSQL：对
NUMERIC类型的精度处理很完美，但遇到超大整数（比如9223372036854775807::BIGINT）取绝对值时，会直接溢出报错。 - SQLite：没有单独的
ABS函数，它用的是小写的abs()。而且它对字符串的处理相当宽松，比如abs('-5')会返回 5，但这种隐式转换的行为很不靠谱。 - Oracle：
ABS支持BINARY_FLOAT和BINARY_DOUBLE，但如果传入NaN，它不会报错，而是直接返回NaN。
跨库迁移的时候，千万别想当然地以为 ABS 能在所有数据库里都容忍类型错误。生产环境里，最稳妥的做法还是用显式的 CAST 或者在上游先做一遍数据校验，确保喂给函数的每个数据都是干干净净的。
