SQL中ROUND函数对0.5的处理机制及强制四舍五入方法

SQL里的 ROUND() 看起来就是普通的“四舍五入”，但真正遇到末位恰好为 0.5 时，结果并不一定在所有数据库、所有数据类型中完全相同。最典型的情况是：精确数值类型通常会把中间值向远离 0 的方向舍入，而某些浮点数计算可能采用“舍入到最近偶数”，于是 2.5 有时得到 3，有时却可能得到 2。

因此，如果业务明确要求“遇到 5 必须按传统规则进位”，不要只检查 SQL 中有没有写 ROUND()，还应该确认数据库类型、字段类型以及表达式计算过程中是否已经变成浮点数。对于金额、计费、积分等需要确定结果的场景，优先使用 DECIMAL 或 NUMERIC 等精确类型；必要时还可以使用 FLOOR()、CEILING() 和 CASE 明确写出舍入规则。

一、ROUND遇到0.5时到底发生了什么

假设现在希望把一个数保留到整数位。普通数值很好理解：

ROUND(2.4, 0)  →  2
ROUND(2.6, 0)  →  3

真正容易出现差异的是刚好处于两个候选结果中间的数：

2.5

它与 2、3 的距离都恰好是 0.5，因此数据库需要额外使用一条“中间值规则”决定到底选哪个结果。

常见的两种规则是：

二、为什么同样的ROUND(2.5)可能得到不同结果

判断 ROUND() 的结果时，一个非常关键的问题是：参与计算的是精确十进制数，还是近似浮点数。

1. DECIMAL和NUMERIC属于精确数值类型

DECIMAL、NUMERIC 通常按照十进制精确保存数值。例如金额 2.50 可以准确表达为 2.50，而不是一个非常接近 2.50 的二进制近似值。

以 MySQL 的精确数值为例，官方文档明确说明：精确值遇到恰好处于中间的情况时，采用远离 0 的舍入方式，所以：

SELECT ROUND(CAST(2.5 AS DECIMAL(10,2)), 0);
-- 结果：3

SELECT ROUND(CAST(-2.5 AS DECIMAL(10,2)), 0);
-- 结果：-3

PostgreSQL 的 numeric 也采用中间值远离 0 的规则；SQL Server 的 ROUND() 同样明确采用这种商业舍入规则。

2. FLOAT、REAL、DOUBLE属于近似数值

浮点类型的问题并不是单纯“ROUND写错了”，而是很多十进制小数无法用二进制浮点格式精确表示。

例如数据库表面上看到的是：

2.5
2.675
1.005

但表达式真正参与计算时，其中一些值可能只是非常接近目标十进制数。对于刚好位于舍入边界附近的数，这一点差异就可能改变最终结果。

而且部分数据库对浮点数的中间值处理本身就可能与精确十进制类型不同。MySQL 文档指出，近似值的 ROUND() 结果依赖底层 C 库，在很多系统上会采用“最近偶数”；PostgreSQL 也说明，double precision 的中间值规则与平台有关，而最近偶数是常见行为。

三、不要把所有“.5问题”都归咎于ROUND函数

实际开发中还有一种情况很容易被误判：你认为输入值是一个标准的 x.x5，实际上它经过浮点计算以后已经不是精确的中间值。

例如：

价格 × 折扣率
平均值
百分比
多列 FLOAT 相加
DOUBLE 类型之间的乘除

经过这些计算以后，一个理论上的 2.675 可能变成略小或略大于 2.675 的近似值。此时要求保留两位小数，数据库处理的其实并不是数学意义上绝对精确的 2.675。

所以遇到类似问题时，不要只执行：

SELECT ROUND(value, 2);

还要检查 value 的字段类型，以及产生 value 的整个表达式。如果业务本身需要十进制精确运算，应尽量从数据存储阶段就使用合适的 DECIMAL 或 NUMERIC 类型，而不是等到最后调用 ROUND() 时再补救。

四、强制采用传统四舍五入，推荐先转为精确数值

如果业务规则是：末位小于 5 舍去，末位达到 5 时向远离 0 的方向进位，那么比较稳妥的方法是先保证输入属于精确十进制类型，再使用数据库已经定义清楚的 ROUND()。

MySQL

SELECT ROUND(CAST(2.5 AS DECIMAL(20, 8)), 0);
SELECT ROUND(CAST(-2.5 AS DECIMAL(20, 8)), 0);

SELECT ROUND(CAST(12.345 AS DECIMAL(20, 8)), 2);
SELECT ROUND(CAST(-12.345 AS DECIMAL(20, 8)), 2);

按照 MySQL 对精确值的规则，上面的中间值采用远离 0 的方向舍入。

PostgreSQL

SELECT ROUND(CAST(2.5 AS NUMERIC), 0);
SELECT ROUND(CAST(-2.5 AS NUMERIC), 0);

SELECT ROUND(CAST(12.345 AS NUMERIC), 2);
SELECT ROUND(CAST(-12.345 AS NUMERIC), 2);

PostgreSQL 的 numeric 在中间值时采用远离 0 的规则。

SQL Server

SELECT ROUND(CAST(2.5 AS DECIMAL(20, 8)), 0);
SELECT ROUND(CAST(-2.5 AS DECIMAL(20, 8)), 0);

SELECT ROUND(CAST(12.345 AS DECIMAL(20, 8)), 2);
SELECT ROUND(CAST(-12.345 AS DECIMAL(20, 8)), 2);

SQL Server 的 ROUND() 明确使用 half away from zero，也就是中间值向远离 0 的方向舍入。

五、不依赖ROUND的显式四舍五入写法

有些项目希望把业务规则直接写在 SQL 中，使代码阅读者一眼就能知道“0.5 必须进位”。这时可以使用 FLOOR() 和 CEILING() 自己构造规则。

只处理非负数：FLOOR(x + 0.5)

如果数据保证大于等于 0，舍入到整数可以写成：

FLOOR(value + 0.5)

例如：

保留两位小数时，则把数值放大 100 倍：

FLOOR(value * 100 + 0.5) / 100

例如 12.345：

12.345 × 100 = 1234.5
1234.5 + 0.5 = 1235
FLOOR(1235) = 1235
1235 / 100 = 12.35

同时处理正数和负数

直接对负数使用 FLOOR(value + 0.5) 会改变预期规则，因此如果希望实现“中间值远离 0”，需要区分正负号。

保留整数可以写成：

CASE
    WHEN value >= 0
        THEN FLOOR(value + 0.5)
    ELSE
        CEILING(value - 0.5)
END

例如：

 2.5 → FLOOR(3.0)   →  3
-2.5 → CEILING(-3)  → -3

如果要保留两位小数，可以写成：

CASE
    WHEN value >= 0
        THEN FLOOR(value * 100 + 0.5) / 100
    ELSE
        CEILING(value * 100 - 0.5) / 100
END

其中 100 就是 10²。需要保留三位时可改成 1000。

六、怎样验证当前数据库实际使用了哪种规则

如果接手的是旧系统，最可靠的办法不是根据经验猜，而是在当前数据库环境中直接测试几个具有代表性的边界值。

可以从下面几个值开始：

2.5
3.5
-2.5
-3.5
1.25
1.35

测试整数舍入：

SELECT
    ROUND(2.5, 0),
    ROUND(3.5, 0),
    ROUND(-2.5, 0),
    ROUND(-3.5, 0);

如果结果类似：

3, 4, -3, -4

说明这些输入在当前情况下表现为中间值远离 0。

如果类似：

2, 4, -2, -4

则表现出了最近偶数舍入的特征。

不过只测试字面量仍然不够。如果实际业务字段是 FLOAT、DOUBLE 或复杂表达式，还应该直接测试真实字段类型，例如 MySQL 中可以把精确值与科学计数法形式进行对比：

SELECT
    ROUND(2.5) AS exact_value,
    ROUND(25E-1) AS approximate_value;

MySQL 官方给出的示例中，精确值 2.5 与近似值 25E-1 就可能得到不同结果。

七、实际业务中应该选哪种方法

如果只是一般统计、展示数据，而且数据库当前的 ROUND() 行为已经符合需求，直接使用函数即可，没有必要把简单问题复杂化。

例如金额字段本身就是 DECIMAL，数据库对精确值的中间规则又明确符合项目要求，那么：

ROUND(amount, 2)

通常就是最清晰的写法。

如果数据原本使用 FLOAT 或 DOUBLE，而业务要求金额舍入必须严格一致，则应该优先考虑修改数据链路，让参与计算的值进入精确十进制类型：

ROUND(CAST(amount AS DECIMAL(20, 8)), 2)

如果项目还要求规则本身必须直接体现在 SQL 中，则可以采用：

CASE
    WHEN amount >= 0
        THEN FLOOR(CAST(amount AS DECIMAL(20, 8)) * 100 + 0.5) / 100
    ELSE
        CEILING(CAST(amount AS DECIMAL(20, 8)) * 100 - 0.5) / 100
END

上面的 DECIMAL(20,8) 只是示例精度。实际字段的整数位和小数位要根据业务数值范围确定，不能机械照搬。

八、几个容易出现的误区

误区1：ROUND一定等于传统四舍五入

不能这样判断。具体结果可能受到数据库产品、参数类型以及浮点实现的影响。特别是 FLOAT、REAL、DOUBLE，不能只看到 SQL 中写了 ROUND() 就认定所有 .5 都会远离 0。

误区2：给浮点数加0.5就彻底解决问题

FLOOR(x + 0.5) 只是明确了舍入公式，并不能把已经存在的浮点近似值自动变成精确十进制数。

误区3：负数也直接使用FLOOR(x + 0.5)

这是比较常见的错误。传统中间值远离 0 的规则下：

-2.5 → -3

因此负数应该使用与正数方向对应的 CEILING(x - 0.5)。

误区4：显示两位小数就代表已经按两位计算

格式化显示和数值舍入是两个问题。前端把 12.345 显示成 12.35，并不意味着数据库中的原始值已经变成 12.35。涉及汇总、税费、金额比较时，应明确在哪一步真正执行数值舍入。

九、总结