abs函数在where子句中可直接使用，但需避免对索引列施加函数（如abs(price)>100），否则破坏sargability；推荐改写为price>100 or price
ABS函数在WHERE子句中直接使用是否可行
完全可行，ABS() 是标准SQL标量函数，在 WHERE 子句中可直接调用，无需子查询或CTE。但要注意：它不会阻止索引使用——前提是表达式不破坏索引列的“SARGable”特性（即不能对索引列本身做函数运算）。
常见错误是写成 WHERE ABS(price - 100) 却给 <code>price 字段建了索引，这时数据库无法走索引范围扫描，会退化为全表扫描。
- ✅ 安全用法：
WHERE ABS(-50)、WHERE ABS(some_column) > 100（当some_column未被索引，或你本就不依赖索引时） - ❌ 高风险用法：
WHERE ABS(price) > 100（若price有索引，建议改写为WHERE price > 100 OR price ） - ⚠️ 注意：PostgreSQL 12+ 支持函数索引，可建
CREATE INDEX idx_abs_price ON t (ABS(price))，但 MySQL 目前不支持函数索引（8.0.13+ 仅支持生成列上的索引）
MySQL与PostgreSQL中ABS的参数兼容性差异
ABS() 在主流数据库中都接受数值型参数（TINYINT、DECIMAL、FLOAT 等），但对 NULL 和非数字类型的处理略有不同。
- 所有数据库：输入
NULL→ 返回NULL；在WHERE中，NULL判定为 false，该行被过滤掉 - MySQL：自动尝试隐式转换，
ABS('−12.5')返回12.5，但ABS('abc')返回0（不报错，易埋隐患） - PostgreSQL：严格类型检查，
ABS('−12.5')直接报错ERROR: function abs(text) does not exist，必须显式转类型：ABS('−12.5'::numeric) - 建议统一显式转换：
ABS(CAST(score AS DECIMAL))或ABS(COALESCE(score, 0))避免意外结果
用ABS实现“偏离中心值±N”的过滤逻辑
这是 ABS() 最典型的业务场景，比如“查找价格偏离平均值不超过15元的商品”。关键在于避免在 WHERE 中重复计算聚合值。
- ❌ 错误示范（不可用）：
WHERE ABS(price - AVG(price)) —— 聚合函数不能直接出现在 <code>WHERE中 - ✅ 正确做法一（子查询）：
SELECT * FROM products WHERE ABS(price - (SELECT AVG(price) FROM products))
- ✅ 正确做法二（窗口函数，推荐）：
SELECT * FROM ( SELECT *, ABS(price - AVG(price) OVER()) AS diff_from_avg FROM products ) t WHERE diff_from_avg
- ⚠️ 注意：如果数据量大，
AVG()计算本身有开销；可考虑提前查出均值存变量（MySQL用户可用@avg_price := (SELECT AVG(price) FROM products)），再在主查询中引用
ABS配合ORDER BY做“就近排序”时的性能陷阱
例如“按离目标分值30的绝对距离升序排列”，写成 ORDER BY ABS(score - 30) 很直观，但多数数据库无法利用索引加速该排序，会触发文件排序（Using filesort）。
- 小数据量（
- 大数据量：若
score有索引，可拆解为两路查询再合并：(SELECT * FROM t WHERE score >= 30 ORDER BY score LIMIT 10) UNION ALL (SELECT * FROM t WHERE score ，再在应用层合并去重 - 更稳妥方案：增加生成列（MySQL 5.7+/8.0）：
ALTER TABLE t ADD COLUMN dist_to_30 INT AS (ABS(score - 30)) STORED，然后对该列建索引
真正麻烦的不是语法，而是当 ABS() 出现在过滤或排序中时，你得时刻问自己一句：这个字段有没有索引？数据库能不能跳过全表扫描？
