ROUND函数基本用法为ROUND(number, decimals)，number为数值表达式，decimals为保留位数：正数表示小数点后位数（如ROUND(3.14159,2)→3.14），0表示四舍五入到整数（ROUND(2.7)→3），负数表示向左舍入（ROUND(1234.56,-2)→1200）。
ROUND函数的基本用法和参数含义
ROUND 在大多数主流数据库（如 MySQL、PostgreSQL、SQL Server）中都支持，但行为有细微差别。核心用法是 ROUND(number, decimals)，其中 number 是要处理的数值表达式，decimals 是保留的小数位数（可为负数）。注意：MySQL 和 SQL Server 默认使用“四舍五入”，而 PostgreSQL 的 ROUND 也是标准四舍五入，但某些旧版本或特定配置下可能受 locale 影响——实际使用时建议显式测试。
-
decimals为正数：保留小数点后指定位数，例如ROUND(3.14159, 2)→3.14 -
decimals为 0：四舍五入到整数，例如ROUND(2.7)→3 -
decimals为负数：向左舍入，例如ROUND(1234.56, -2)→1200
不同数据库对 ROUND 的实现差异
MySQL 的 ROUND 使用“银行家舍入”（即偶数舍入）吗？不。MySQL 5.7+ 明确采用算术四舍五入（非银行家舍入），这点常被误传。但 SQL Server 的 ROUND 在 decimal 类型上表现稳定，而在 float 上可能因二进制精度丢失导致意外结果，比如 ROUND(1.235, 2) 有时返回 1.23 而非 1.24——本质是 1.235 在 float 中实际存储为略小于它的值。
- 遇到浮点误差时，优先把字段转成
DECIMAL再ROUND，例如ROUND(CAST(price AS DECIMAL(10,3)), 2) - PostgreSQL 不支持省略
decimals参数（必须显式写ROUND(x, 0)），否则报错function round(double precision) does not exist - SQLite 的
ROUND只接受两个参数，且第二个参数不能为 NULL
在 SELECT 查询中安全使用 ROUND 的实操建议
直接在 SELECT 中套用 ROUND 很常见，但容易忽略数据类型继承问题：ROUND 返回值类型通常与输入一致，若原字段是 FLOAT，结果仍是近似值；若需精确展示（比如金额），应配合类型转换。
- 避免写
ROUND(sales_amount, 2) AS amount然后在应用层再格式化——这可能导致前端二次四舍五入出错 - 聚合场景下慎用，例如
ROUND(AVG(score), 1)是先算平均再舍入，而AVG(ROUND(score, 1))是先舍入每个值再平均，结果可能不同 - WHERE 条件里一般不要用
ROUND做比较，比如WHERE ROUND(price, 2) = 9.99，会阻止索引使用，且浮点误差放大匹配失败风险
替代方案：当 ROUND 不够用时怎么办
如果需要严格控制舍入方向（如向上取整用于计费），ROUND 就不够用了。这时候得换函数：CEILING 向上、FLOOR 向下、TRUNCATE（MySQL）或 TRUNC（PostgreSQL）截断而非舍入。另外，显示格式化（如补零）不属于 ROUND 职责，应该交给应用层或数据库的格式化函数（如 MySQL 的 FORMAT()），但注意 FORMAT() 返回字符串，不能再参与数值计算。
- 要保留两位小数且补零显示（如
5.0→5.00），用CAST(ROUND(x, 2) AS DECIMAL(10,2))，别依赖FORMAT(x, 2) - Oracle 用户注意：
ROUND行为一致，但默认数值类型是NUMBER，精度更可靠；不过ROUND对BINARY_FLOAT仍可能有误差 - 如果业务要求“遇 5 必进”，而数据库实际用了银行家舍入（如某些 SQLite 编译选项），就得绕开
ROUND，改用条件表达式模拟
ROUND(2.675, 2) 的结果——浮点表示的不可靠性比想象中更常干扰判断。 
