ABS()只接受一个数值表达式参数，传入字符串、日期、JSON或多个参数均会报错；需确保列类型为INT/DECIMAL/FLOAT，必要时用CAST显式转换，且WHERE中使用ABS会导致索引失效。
ABS()只接受一个参数，传多参或字符串会报错
ABS()不是万能转换器，它只认数值表达式。写成 ABS(a, b) 或 ABS('−5') 一定会出错：MySQL 报 Incorrect number of arguments to function ABS()，PostgreSQL 直接拒绝并提示 function abs(text) does not exist。字符串、日期、JSON 字段都不能直接喂给 ABS()。
实操建议：
- 查表结构确认列类型是
INT、DECIMAL或FLOAT，别靠猜测 - 不确定时先用
CAST(column AS NUMERIC)显式转类型，比依赖隐式转换更可控 - 想处理字符串数字（如 '-123'），得先用
TO_NUMBER()（PostgreSQL）或CONVERT()（SQL Server）转成数值，再套ABS()
WHERE 中用 ABS(price) > 100 会导致索引失效
哪怕 price 列上有 B-tree 索引，WHERE ABS(price) > 100 也基本等于放弃索引——数据库没法把函数计算提前到索引查找阶段。实际执行往往是全表扫描。
实操建议：
- 真要筛“绝对值大于 100”，优先拆成两个范围：
WHERE price > 100 OR price ，这样能走索引 - 如果业务逻辑确实绕不开
ABS()（比如动态阈值），且查询高频，考虑建函数索引：CREATE INDEX idx_abs_price ON t ((ABS(price)))（PostgreSQL/Oracle 支持；MySQL 8.0.13+ 支持函数索引但语法略异） - 别在 JOIN 条件里写
ABS(a.x - b.y) ，改用 <code>a.x BETWEEN b.y - 5 AND b.y + 5预筛选
NULL 和浮点精度是静默陷阱
ABS(NULL) 永远返回 NULL，不报错但可能让整行从结果中消失——尤其在 WHERE ABS(diff) > 0 这类条件里，含 NULL 的记录直接被过滤掉，你甚至看不出少了谁。
浮点数更麻烦：ABS(-0.1 - 0.2 + 0.3) 在多数库中不等于 0，而是 5.55e-17 这种极小值。表面看是精度问题，本质是 IEEE 754 表示局限。
实操建议：
- 涉及比较时加容差：
ABS(a - b) 替代 <code>ABS(a - b) = 0 - 聚合前兜底：
AVG(ABS(COALESCE(profit, 0)))，别指望ABS()自动处理NULL - 对关键业务字段（如金额、温度），存入时就用
DECIMAL而非FLOAT，从源头规避浮点误差
ORDER BY ABS(score) 排序无法利用索引
写 ORDER BY ABS(score) 是合法的，也能得到想要的顺序（比如 -8、3、-5 → 3、5、8），但数据库不会用 score 上的索引加速这个排序。数据量一过百万，延迟就明显。
实操建议：
- 如果固定按某个基准值的绝对偏差排序（如离 85 分最近），且查询频繁，建生成列：
ALTER TABLE exam_results ADD COLUMN abs_diff INT GENERATED ALWAYS AS (ABS(score - 85)) STORED（MySQL）或ADD COLUMN abs_diff INT AS (ABS(score - 85))（SQL Server），再给该列建索引 - 避免嵌套：
ORDER BY ABS(ROUND(x * 100) / 100)这种写法不仅慢，还可能因中间舍入放大误差 - 注意 NULL 排序位置：PostgreSQL 默认
NULLS FIRST，ORDER BY ABS(score) NULLS LAST才能把空值排到最后
真正容易被忽略的是：ABS() 不是数据清洗操作，它不改变原值，只提供一种视角。用之前先问一句——你丢掉符号后，是否还能还原业务含义？比如账户变动 -500 和 +500 绝对值相同，但一个是充值一个是提现，混在一起统计“总变动额”可能掩盖风险。
