ABS()函数用于取绝对值,但WHERE中对列使用ABS()会破坏索引有序性,导致全表扫描;应改写为WHERE id > 100 OR id
MySQL里
ABS()不是只防负数,它影响索引和排序逻辑直接用
ABS()做WHERE条件,比如WHERE ABS(id) > 100,MySQL大概率放弃索引走全表扫描——因为函数作用在列上会破坏索引的有序性。常见错误现象:
EXPLAIN显示type=ALL,查询变慢,尤其在大表上明显。
- 想查“绝对值大于100的记录”,优先改写为
WHERE id > 100 OR id ,保留索引能力ABS()适合用在SELECT或ORDER BY里,比如ORDER BY ABS(score - 85)找最接近85分的学生- 注意浮点数精度:对
DECIMAL字段用ABS()没问题,但对FLOAT可能暴露底层二进制表示误差用
ROUND()时别默认四舍五入,小数位数和取整方向得看场景
ROUND()在MySQL里默认是“银行家舍入”(偶数舍入),不是数学意义上的四舍五入。比如ROUND(2.5)和ROUND(3.5)都返回4,而ROUND(1.5)返回2、ROUND(0.5)返回0——因为要向最近的偶数靠拢。
- 财务计算需要严格四舍五入?改用
ROUND(x + 0.5 - (x 手动模拟,或先转成DECIMAL(10,1)再处理- 想截断小数不四舍五入?用
FLOOR(x * 10) / 10代替ROUND(x, 1),避免意外进位ROUND(999.999, -1)结果是1000,负数位数表示向左取整,容易误以为是“保留十位”,其实是“按十位四舍五入”
FLOOR()和CEILING()不能互换,特别是涉及负数和时间计算时
FLOOR(-2.7)返回-3,不是-2;CEILING(-2.7)才返回-2。这个反直觉行为在分页、分桶、时间对齐时特别容易出错。
- 分页取第n页(每页20条):用
(page_no - 1) * 20比FLOOR((page_no - 1) * 20)更安全,后者在page_no是表达式且含小数时可能越界- 把时间戳对齐到整小时:用
FLOOR(UNIX_TIMESTAMP(dt) / 3600) * 3600,别用ROUND(..., -3),否则跨小时会偏移FLOOR()返回的是DECIMAL或BIGINT类型,和原字段类型可能不一致,JOIN或聚合时留意隐式转换开销数值函数嵌套时,NULL传播和类型隐式转换常被忽略
只要输入里有
NULL,ABS()、ROUND()、FLOOR()全都返回NULL,不会报错也不会跳过——这在GROUP BY或WHERE中容易漏掉数据。
- 检查字段是否为空:先用
IFNULL(col, 0)兜底,再套数值函数,别依赖“业务上不会为NULL”ROUND('123.45')能运行,但字符串转数字有隐式开销;如果字段是VARCHAR存数字,建议建生成列或提前清洗- 在JSON字段里提取数值后直接算?
ROUND(JSON_EXTRACT(data, '$.price'))可能因JSON类型是字符串而失败,加+ 0强制转数:ROUND(JSON_EXTRACT(data, '$.price') + 0)这些函数看着简单,但一旦混进WHERE、GROUP BY、子查询或者和JSON/时间戳一起用,边界情况就藏不住了。












