MySQL的ROUND()默认采用银行家舍入（四舍六入五成双），非传统四舍五入，如ROUND(2.5,0)返回2；TRUNCATE()是硬截断，不判断下一位数字，如TRUNCATE(3.999,2)返回3.99；二者逻辑本质不同，且均受数据类型（如FLOAT精度误差）和参数误用影响。
MySQL 的 ROUND() 不是传统四舍五入，TRUNCATE() 也不是“四舍五入的简化版”——它们行为完全不同，且都容易因数据类型和参数误用导致结果出错。
ROUND 默认是银行家舍入，不是你数学课学的那个
比如 ROUND(2.5, 0) 返回 2，ROUND(3.5, 0) 返回 4。这不是 bug，是设计：当舍去位刚好是 5 时，看前一位奇偶来决定进还是舍（偶舍奇入）。这对统计更公平，但业务上常被当成错误。
- 财务、报表、前端展示等场景若要求“无条件向上/向下/传统四舍五入”，不能直接依赖
ROUND() - 想强制传统四舍五入，可用偏移法：
ROUND(x + 0.5 * SIGN(x), d)，但要注意x为负数时SIGN(x)是-1，否则会反向偏移 - 浮点列（如
DOUBLE）参与ROUND()前已存在二进制精度误差，例如1.15可能存成1.1499999999999999，ROUND(1.15, 1)就可能得1.1而非1.2
TRUNCATE 是硬截断，不看下一位数字
TRUNCATE(3.999, 2) → 3.99；TRUNCATE(-1.999, 1) → -1.9。它不做任何判断，只按位数砍掉，连“舍”都不发生。
- 别和 DDL 的
TRUNCATE TABLE混，完全无关 - MySQL 支持
TRUNCATE(x, y)，PostgreSQL 要用TRUNC(x, y)（函数名不同） - 负数
y行为一致：TRUNCATE(123.45, -1)→120，但 SQLite 不支持负y - 如果字段是
VARCHAR存数字，必须先CAST(... AS DECIMAL)，否则TRUNCATE()可能静默失败或报错
DECIMAL 字段定义本身就会截断，ROUND 根本没机会生效
建表写 price DECIMAL(10,2)，插入 9.995，查出来就是 9.99——不是 ROUND() 没起作用，是插入时就被截断了，且不可逆。
-
DECIMAL(M,D)的D是存储精度上限，超长部分直接丢弃（非四舍五入） - 想保留中间计算精度，字段应预留余量，比如预期展示 2 位小数，可设
DECIMAL(10,4)，再在查询时ROUND(col, 2) - 用
SHOW COLUMNS FROM table_name确认字段真实定义，别信业务文档或印象
ROUND 用在 GROUP BY 或 ORDER BY 里可能分错组、排错序
对 DOUBLE 类型字段做 ROUND(price, 1) 分组，本该归为同一组的 1.15 和 1.1499999999999999 可能被算成不同值，导致计数异常或排序跳跃。
- 根源是浮点数二进制表示无法精确表达十进制小数
- 解决办法：要么把原始列转成
DECIMAL再ROUND，要么改用CAST(ROUND(..., d) AS DECIMAL(10,d))强制落地精度 - 临时方案：用
TRUNCATE()替代ROUND()做分组键（如果业务允许截断而非舍入）
最常被忽略的一点：ROUND 和 TRUNCATE 的行为差异，不是“精度高低”的问题，而是“逻辑本质不同”——一个是舍入规则，一个是位数裁剪。选错函数，比参数写错后果更严重。
