WHERE中用ABS()过滤绝对值条件必须写对表达式，如查价格波动超±50应写WHERE ABS(price - avg_price) > 50，而非WHERE price > ABS(50)；需避免对索引列直接套ABS()导致全表扫描，并注意NULL处理、类型兼容性及浮点精度问题。
WHERE 中用 ABS() 过滤“绝对值条件”必须写对表达式
想查“价格波动超过 ±50 的商品”，不能写 WHERE price > ABS(50)——这等价于 WHERE price > 50，完全漏掉负向异常。正确写法是 WHERE ABS(price - avg_price) > 50。
常见错误还包括把 ABS() 当成数据清洗手段塞进 WHERE，比如 WHERE ABS(balance) IS NOT NULL：这毫无意义，因为 ABS(NULL) 仍返回 NULL，判断逻辑没变。真要排除空值，得前置用 WHERE balance IS NOT NULL。
- 筛选“绝对值大于阈值”的记录 → 用
WHERE ABS(col) > N - 只保留非负原始值（如合法库存）→ 直接
WHERE col >= 0，更高效且能走索引 - 业务明确依赖差值幅度（如评分偏差、温度变化）→ 才该用
ABS(col - baseline)
SELECT 中用 ABS() 需主动处理 NULL 和类型隐式转换
ABS() 对 NULL 输入安静返回 NULL，不报错但可能让后续 SUM() 或 AVG() 结果失真。例如统计账户余额绝对值均值时，若 balance 有空值，AVG(ABS(balance)) 会跳过这些行，但你未必意识到它们本应被归零或标记。
不同数据库对非数值字段的容忍度差异大：SQLite 会把文本字段强行转数字（失败则返 0），PostgreSQL 则直接报错。MySQL 8.0 对 DOUBLE 类型的 ABS() 可能因 C 库实现返回极小正数（如 ABS(-0.1e-15) ≠ 0）。
- 防
NULL干扰：优先用COALESCE(col, 0)包裹，再套ABS() - 避免隐式转换风险：确保列类型为
INT、DECIMAL或FLOAT，别依赖字符串自动转数字 - 跨库兼容写法：
SELECT ABS(COALESCE(sales_delta, 0)) AS abs_delta FROM reports;
ORDER BY ABS(col) 会绕过索引，高频场景需提前建计算列
写 ORDER BY ABS(score) 确实能让 -8、3、-5 按 3→5→8 排，但数据库无法利用 score 字段上的普通索引，每次执行都触发全表扫描。
如果这个排序是高频操作（比如后台风控看“偏离均值最大的前 10 条记录”），别指望应用层二次排序来补救——网络传输和内存压力反而更大。
- MySQL 5.7+：加持久化生成列
abs_score INT AS (ABS(score)) STORED，再对它建索引 - PostgreSQL：用函数索引
CREATE INDEX idx_abs_score ON table_name (ABS(score)); - 临时方案：若仅偶尔查，接受性能损耗；但上线前务必用
EXPLAIN确认是否走了索引
ABS() 嵌套或参与浮点运算时，精度问题往往藏在 ROUND() 前面
ABS() 本身不引入误差，但上游计算可能已丢失精度。典型例子是先 ROUND() 再取绝对值：ABS(ROUND(1.23456789 * 1000000) / 1000000)，结果可能是 1.234568 而非原始值。
更隐蔽的是浮点类型自身限制：PostgreSQL 中 ABS(-0.1::REAL) 和 ABS(-0.1::NUMERIC) 显示一样，但在 GROUP BY 或 JOIN 时可能因二进制表示差异导致分组分裂或关联失败。
- 涉及比较或分组时，优先用
NUMERIC/DECIMAL类型存关键数值 - 避免
ABS()套ROUND()或CAST()，尽量把精度控制放在最外层 - 测试边界值：比如
ABS(-0.0)在各库中是否恒等于0.0，别默认它“安全”
实际用的时候，最容易被忽略的是 ABS() 在 WHERE 和 ORDER BY 中引发的索引失效，以及浮点数参与时那层看不见的精度漂移——这两处不测 EXPLAIN、不验边界值，上线后就容易出数据对不上或慢查询告警。
