MySQL、Oracle和SQL Server中四舍五入规则的差异

在数据库开发与数据迁移过程中，数值计算的精确度直接关系到财务对账、报表汇总与计费逻辑的准确性。在标准定点数（例如各数据库的定点数值类型）环境中，MySQL、Oracle 和 SQL Server 的 ROUND 函数基础计算均遵循“向远离零方向舍入（Round Half Away From Zero）”原则，即遇到正数 0.5 进位、遇到负数 -0.5 绝对值增大退位。然而，当深入到函数参数控制、浮点数底层实现以及类型转换机制时，三者之间存在着不容忽视的关键差异。

导致跨数据库计算结果出现分歧的核心机制集中在三个维度：一是 SQL Server 独有的第三参数支持直接截断，而 MySQL 与 Oracle 必须使用独立的截断函数；二是 MySQL 的近似浮点类型在部分底层系统运行时会退化为“向最近偶数舍入（Round Half to Even，亦称银行家舍入）”，而 Oracle 与 SQL Server 的定点机制更加严谨；三是在执行数据类型转换（例如转换为整数）时，MySQL 与 Oracle 默认自动四舍五入，而 SQL Server 则是直接截断小数部分。

三大数据库 ROUND 函数的参数结构与截断机制

同样是执行数值四舍五入与精度截取，各个数据库在函数接口设计上体现了不同的工程思路。开发人员经常面临一个实际问题：能否直接通过 ROUND 函数舍弃小数位而不再进行四舍五入？各个数据库的语法结构与支持能力如下：

1. MySQL 中的 ROUND 语法与截断限制

在 MySQL 中，ROUND(X [, D]) 仅接收两个参数：目标数值 X 和保留小数位数 D。当省略 D 时，系统默认将其视作 0 进行取整。需要特别注意的是，MySQL 的 ROUND 函数完全不具备截断功能，无法通过传递负数参数或开关参数关闭舍入规则。如果业务需求要求直接舍去指定小数位（不进位），必须显式调用独立的 TRUNCATE(X, D) 函数。

-- 执行环境：MySQL 8.0+ 客户端控制台
-- 测试四舍五入与显式截断
SELECT ROUND(123.456, 2) AS round_result,
       TRUNCATE(123.456, 2) AS truncate_result;

-- 示例输出：
-- +--------------+-----------------+
-- | round_result | truncate_result |
-- +--------------+-----------------+
-- |       123.46 |          123.45 |
-- +--------------+-----------------+

2. Oracle 中的 ROUND 语法与日期扩展

Oracle 的数值舍入函数为 ROUND(n [, integer])，其中参数 n 为目标数值，integer 为保留位数（缺省时为 0）。与 MySQL 相同，Oracle 的 ROUND 无法通过参数开启截断模式；若要无条件舍去小数，必须使用专属的 TRUNC(n [, integer]) 函数。此外，Oracle 的 ROUND 具备极强的类型多态性，不仅适用于数值，还支持直接对日期与时间戳（DATE / TIMESTAMP）进行四舍五入计算（例如将时间按天、月或年舍入至最临近的整点）。

-- 执行环境：Oracle SQL*Plus 或 PL/SQL Developer
-- 测试数值舍入、截断与日期舍入
SELECT ROUND(123.456, 2) AS round_val,
       TRUNC(123.456, 2) AS trunc_val,
       ROUND(TO_DATE('2026-06-16', 'YYYY-MM-DD'), 'MONTH') AS date_round
FROM dual;

-- 示例输出：
-- ROUND_VAL  TRUNC_VAL  DATE_ROUND
-- ---------  ---------  -----------
--    123.46     123.45  2026-07-01

3. SQL Server 的多功能第三参数设计

SQL Server 的 ROUND(numeric_expression, length [, function]) 拥有独特的三参数结构。前两个参数均为必填，其中 length 不能缺省。关键在于可选的第三参数 function：

• 当 function 为 0 或缺省时，系统正常执行四舍五入操作；
• 当 function 为任何非 0 的数值（通常使用 1）时，函数将直接切换为截断模式，直接丢弃目标位置之后的小数，完全不产生进位。

-- 执行环境：SQL Server Management Studio (T-SQL)
-- 测试四舍五入与第三参数截断
SELECT ROUND(123.456, 2, 0) AS round_val,
       ROUND(123.456, 2, 1) AS trunc_val;

-- 示例输出：
-- round_val     trunc_val
-- ------------  ------------
-- 123.460       123.450

从上面的示例输出还可以观察到另一个核心特征：SQL Server 的 ROUND 函数返回的数据类型与输入表达式的类型及其精度定义完全一致。输入类型为保留三位小数的定点数时，即使舍入到整数位（ROUND(val, 0)），输出依然会保留末尾的 .000，不会自动转换为整型或剥离无效零。

负数与临界值 0.5 的舍入算法与数轴落点

当数值的小数部分恰好处于正中央的 0.5 临界点时，数据库如何确定归宿？在正数区间，读者普遍熟知“逢五进一”，但当引入负数以及统计学算法时，舍入逻辑将分化为三种完全不同的数学机制：

1. 向远离零方向舍入（Round Half Away From Zero）

这是中国算术教学中最标准的四舍五入模式，也是三大数据库在处理定点数时的默认标准。其规则为：当待舍弃部分数值等于或大于 0.5 时，数值向离开原点（0）的方向推进：

• 正数区间：2.5 远离零向右推进，结果为 3；1.5 推进为 2；
• 负数区间：-2.5 远离零向左推进，结果为 -3；-1.5 推进为 -2。

该算法的特点是对称美观，绝对值运算规律清晰。在 MySQL、Oracle 与 SQL Server 中对定点数字面量执行 ROUND(-2.5)，均会稳定得到 -3。

2. 银行家舍入法（Round Half to Even）

在金融统计与高频数据分析中，“向远离零方向舍入”存在一个系统性缺陷：如果大量数据的尾数均为 0.5，始终向外进位会导致求和汇总值产生持续的正向累积偏差。为了消除这一偏差，电气与电子工程师学会（IEEE）在浮点标准中推荐了“向最近偶数舍入”法则，在业内通常被称为“银行家舍入”或“四舍六入五成双”：

• 当待舍弃位数刚好为 5 且后面无有效数字时，观察前一位数字：若前一位为奇数则进位为偶数，若前一位已为偶数则舍弃；
• 针对临界值：1.5 舍入为 2（因为 1 是奇数，向偶数 2 进位）；2.5 舍入为 2（因为 2 本身是偶数，直接舍去 0.5）；
• 在负数区间同样向最近偶数收敛：-1.5 变为 -2，-2.5 同样收敛为 -2。

3. 朝零截断（Round Toward Zero）

朝零截断即前文所述的截断操作。无论正数还是负数，直接削去目标精度之外的全部小数部分，使计算结果单向朝坐标原点（0）收缩：+2.5 截断为 +2，-2.5 截断为 -2。

数据类型陷阱：FLOAT 与 DECIMAL 为何结果各异？

许多数据库开发人员在实测时会遇到令人困惑的现象：在同一个 MySQL 实例中，执行 SELECT ROUND(2.5) 返回 3，但执行 SELECT ROUND(CAST(2.5 AS DOUBLE)) 却可能得到 2。这正是由于底层存储类型导致的舍入机制分流。

1. 精确数值类型（DECIMAL / NUMERIC / NUMBER）

定点数在数据库底层采用十进制结构编码，数值以基数块或精确字符串数组存储。例如 Oracle 的 NUMBER 采用内部以 100 为基数的十进制浮点表示，MySQL 采用每 9 位十进制数字压缩为 4 字节的定点结构。这类数据类型不存在二进制浮点转换误差，其四舍五入由数据库内核自研的高精度算术库执行，因此在 MySQL、Oracle 与 SQL Server 中表现完全一致，始终稳定执行“向远离零方向舍入”。

2. 近似数值类型（FLOAT / DOUBLE / REAL）

近似数值类型严格遵循二进制浮点数编码规范。在二进制体系中，虽然 0.5（二进制的 0.1）能够精确表示，但许多看似简单的十进制小数（例如 0.1、0.2、0.15）在二进制中是无限循环小数。当经过算术加减乘除后，字面上的 2.5 实际在内存中的存储值可能变成了 2.4999999999999994 或者 2.5000000000000001：

• MySQL 的浮点分流：MySQL 官方设计规定，针对浮点数（FLOAT / DOUBLE）的 ROUND 操作交由底层操作系统 C 运行时库的 round() 或 rint() 函数处理。在多数现代 Linux/Unix 发行版中，C 库遵循标准银行家舍入（Round to Nearest Even），这就导致浮点数经常展现出五成双特性；若加上精度微差，则结果更加不可控；
• Oracle 的类型隔离：Oracle 的主力字段类型为 NUMBER，默认绝大部分业务不会触碰二进制浮点数。只有当显式使用 BINARY_FLOAT 或 BINARY_DOUBLE 时，才会引入硬件级浮点运算，此时同样会受到浮点表示微差的干扰；
• SQL Server 的精度漂移：SQL Server 自身的 FLOAT 同样属于近似数值。在结合聚合求和（SUM）后执行 ROUND 时，微小的浮点漂移极易导致边界值判定翻转。

-- 执行环境：MySQL 8.0 终端
-- 验证定点数与浮点数在 ROUND 上的行为差异
SELECT ROUND(2.5) AS exact_decimal_round,
       ROUND(2.5e0) AS approximate_float_round;

-- 示例输出（取决于底层 C 运行时库）：
-- +---------------------+-------------------------+
-- | exact_decimal_round | approximate_float_round |
-- +---------------------+-------------------------+
-- |                   3 |                       2 |
-- +---------------------+-------------------------+

隐式转换与数据写入时的隐藏舍入与截断

在实际编码中，很多开发人员并没有显式编写 ROUND 函数，而是通过类型转换函数（如 CAST / CONVERT）或者直接将计算值 INSERT 到表字段中。在这里隐藏着一个极其危险的跨数据库移植陷阱：整数类型转换究竟是舍入还是截断？

1. 转换为整型（CAST AS INT）的核心分歧

当执行 CAST(12.5 AS ...) 将小数转换为整数时，三大数据库的表现出现了根本分歧：

• MySQL：执行 SELECT CAST(12.5 AS SIGNED)，结果为 13。MySQL 规定小数转整数时自动进行向外四舍五入；
• Oracle：执行 SELECT CAST(12.5 AS INT) 或 CAST(12.5 AS NUMBER(10,0))，结果同样为 13，执行自动四舍五入；
• SQL Server：执行 SELECT CAST(12.5 AS INT)，结果为 12！SQL Server 严格执行向零截断，直接剥除全部小数部分。

如果一段业务逻辑在 MySQL 或 Oracle 中依赖 CAST(amount AS INT) 进行取整，当应用系统迁移到 SQL Server 时，所有带小数的数据都将因截断而少算 1，从而引发严重的计算漏洞。

-- 验证代码：三大数据库中的 CAST(12.5 AS INT) 对比
-- MySQL:
SELECT CAST(12.5 AS SIGNED);  -- 示例输出：13 (隐式四舍五入)

-- Oracle:
SELECT CAST(12.5 AS INT) FROM dual;  -- 示例输出：13 (隐式四舍五入)

-- SQL Server:
SELECT CAST(12.5 AS INT);  -- 示例输出：12 (直接向零截断！)

2. 写入低精度定点数字段时的表现

如果目标并非整型，而是将多位小数写入定义了较低小数位的定点数字段（例如将 12.35 存入 DECIMAL(10, 1) 字段）：

• 在 MySQL 开启严格模式（STRICT_TRANS_TABLES，生产环境默认标准）下，数据会自动四舍五入为 12.4 存入；
• 在 Oracle 中，向 NUMBER(10, 1) 插入 12.35 会自动四舍五入为 12.4；
• 在 SQL Server 中，向 DECIMAL(10, 1) 插入或转换 12.35 同样会自动四舍五入为 12.4。

因此在定点数精度降低时，三大数据库保持了自动四舍五入的默契，真正的破坏性风险完全集中在整型转换的截断机制上。

跨数据库工程实践与兼容性方案

为了在复杂微服务架构、多数据源报表平台或跨数据库迁移项目中保证业务指标的绝对一致，建议遵循以下工程落地方案：

1. 消除隐式转换：整型转换前显式嵌套 ROUND

为了抹平 SQL Server 与 MySQL/Oracle 在 CAST AS INT 上的截断与舍入分歧，任何需要四舍五入转为整型的场景，必须统一书写为：

-- 跨数据库安全兼容写法：显式指定舍入为 0 位后再转整型
SELECT CAST(ROUND(original_value, 0) AS INT);

此写法在 MySQL、Oracle 与 SQL Server 中均能产生完全相同的四舍五入取整结果，彻底切断截断逻辑的触发契机。

2. 规范截断调用：避免跨平台滥用 SQL Server 第三参数

虽然 SQL Server 的 ROUND(val, len, 1) 语法极为简洁，但该参数无法在 MySQL 和 Oracle 中识别。在跨数据库抽象层（如 MyBatis、Jooq 或多源 SQL 构建器）中，若需实现截断逻辑，应根据当前数据库方言适配：

• MySQL 方言：渲染为 TRUNCATE(val, len)；
• Oracle 方言：渲染为 TRUNC(val, len)；
• SQL Server 方言：渲染为 ROUND(val, len, 1)。

3. 核心对比维度与工程决策全景表

下表系统归纳了三大数据库在四舍五入与相关运算中的全维度特性对比，供系统架构设计与运维调优查阅：