ROUND函数在金额计算中默认行为易出错，因MySQL和PostgreSQL默认“四舍六入五成双”，SQL Server和Oracle用传统四舍五入，导致ROUND(2.5,0)等结果不一致；必须配合DECIMAL类型转换与显式舍入逻辑（如CAST(x AS DECIMAL(10,2))再ROUND）确保财务精度。
ROUND函数在金额计算中默认行为容易出错
SQL的ROUND函数对金额四舍五入时，不同数据库的行为不一致——MySQL和PostgreSQL默认使用“四舍六入五成双”（银行家舍入），而SQL Server和Oracle用传统四舍五入。这意味着ROUND(1.5, 0)在MySQL里结果是2，但在某些旧版SQL Server里可能也是2，但ROUND(2.5, 0)在MySQL返回2（因为偶数优先），这会让财务报表出现肉眼难察觉的偏差。
实际处理金额必须显式指定舍入逻辑，不能依赖默认：
- MySQL：用
ROUND(x, d)配合CAST(x AS DECIMAL(10,2))先转精度，再舍入 - PostgreSQL：推荐用
ROUND(x::NUMERIC, 2)，避免浮点误差累积 - SQL Server：
ROUND(x, 2, 0)中第三个参数为0才是标准四舍五入（1表示截断）
金额字段小数位不足时ROUND会补零还是丢精度？
ROUND本身不改变字段定义的小数位数，只影响计算结果的显示值。如果源字段是DECIMAL(10,2)，但存了123.456，它实际被截断为123.46入库；后续再用ROUND(amount, 2)不会“恢复”第三位，而是对已截断值操作。
真正要控制输出格式，得结合类型转换：
- MySQL：
FORMAT(amount, 2)返回字符串，带千分位——不适合计算，仅用于展示 - PostgreSQL：
TO_CHAR(amount, 'FM999999990.00')可强制补零，但结果是文本 - 通用安全做法：
CAST(ROUND(amount, 2) AS DECIMAL(10,2))确保结果仍是数值型且精度可控
ROUND遇到负数金额时怎么算？
负数的四舍五入方向容易误解：ROUND(-1.5, 0)在绝大多数SQL引擎中返回-2（向远离零的方向舍入），不是-1。这符合IEEE标准，但和部分业务预期相反——比如退款金额希望“向上取整”到-1元，而非更亏的-2元。
若需按业务逻辑调整方向，不能只靠ROUND：
- 向上取整（朝零方向）：用
CEILING或ROUND(x + 0.5, 0)（仅适用于正数） - 向下取整（负数变更大）：用
FLOOR，如FLOOR(-1.5)得-2 - 真正安全的负数金额处理：先
ABS，舍入后再加符号，例如SIGN(x) * ROUND(ABS(x), 2)
为什么ROUND(19.999, 2)有时返回19.99而不是20.00？
这是浮点数存储导致的隐式精度丢失。例如19.999在IEEE 754 double中实际存为19.998999999999999...，ROUND对这个略小的值执行四舍五入，自然得19.99。
解决方法只有两个：
- 源头用
DECIMAL或NUMERIC类型存储金额，杜绝浮点表示 - 计算前先做一次精度对齐：
ROUND(CAST(x AS DECIMAL(12,3)), 2)，把输入强制转为精确小数再舍入
绕开ROUND直接用字符串截取或业务层处理，反而更容易引入新问题。关键还是数据类型从入库那一刻就得定死。
