ROUND函数用于SQL数值四舍五入，语法为ROUND(numeric_expression, decimal_places)，decimal_places为正数时保留小数位、0时取整、负数时向左舍入；但MySQL/PostgreSQL/SQL Server等对银行家舍入、浮点精度、NULL处理等行为存在差异，需结合CAST等确保精度。

ROUND函数的基本用法和参数含义

ROUND 在 SQL 中用于四舍五入数值，但不同数据库对第二个参数（小数位数）的处理逻辑有细微差别，直接影响“精确控制”的效果。关键不是“能不能”，而是“在哪个库里怎么写才不踩坑”。

标准语法是 ROUND(numeric_expression, decimal_places)，其中 decimal_places 可正可负：正数表示保留小数点后几位，负数表示向左舍入到整数位（如 -1 → 十位）。

• PostgreSQL 和 SQL Server：支持负数，且严格按四舍五入规则执行
• MySQL：默认使用“银行家舍入”（偶数舍入）吗？不，ROUND() 在 MySQL 5.7+ 是标准四舍五入，但注意它底层用的是浮点运算，对某些值（如 2.5）表现稳定，而 2.65 这类可能因二进制表示产生微小偏差
• SQLite：只接受一个参数，不支持指定小数位——想用 ROUND(x, 2)？会报错 no such function: ROUND

为什么ROUND(1.2345, 2)有时返回1.23，有时返回1.24？

这不是 ROUND 函数的问题，而是输入值本身在数据库中就不是精确的十进制数。比如 1.2345 存在 DECIMAL 字段里是安全的，但如果来自计算（如 price * tax_rate），而字段类型是 FLOAT 或 REAL，那参与 ROUND 的其实是近似值。

• 查一下字段类型：SELECT column_name, data_type FROM information_schema.columns WHERE table_name = 'orders';
• 强制转成高精度类型再舍入：ROUND(CAST(price * tax_rate AS DECIMAL(10,4)), 2)
• 避免用 FLOAT 存金额、百分比等需要确定精度的业务数据

替代方案：当ROUND不满足“绝对可控”需求时

如果业务要求“始终向上取两位小数”或“截断而非四舍五入”，ROUND 就不合适了。这时候得换函数或组合表达式。

• 向下截断两位小数（不四舍五入）：FLOOR(value * 100) / 100.0（适用于 PostgreSQL/SQL Server/MySQL）
• 向上进位两位小数：CEILING(value * 100) / 100.0
• MySQL 特有：TRUNCATE(value, 2) —— 它是截断，不是四舍五入，且不会像 ROUND 那样受浮点误差干扰
• PostgreSQL 中更稳妥的写法：ROUND(value::NUMERIC, 2)，显式转为任意精度数字类型再运算

常见错误：嵌套计算 + ROUND 导致结果异常

写成 ROUND(SUM(amount), 2) 看似合理，但如果 amount 是 FLOAT，先 SUM 再 ROUND，误差已经累积。更糟的是写成 ROUND(amount, 2) AS rounded_amount 然后在外层再 SUM，这属于“先舍入再汇总”，和“先汇总再舍入”结果可能差几分钱。

• 财务场景务必先聚合再舍入：ROUND(SUM(CAST(amount AS DECIMAL(12,2))), 2)
• 不要对中间过程字段反复 ROUND，尤其涉及多步乘除时
• 测试用例建议包含边界值：1.995、2.005、-1.995，验证是否符合预期的舍入方向

实际应用中最容易被忽略的，是字段原始类型的隐式影响——哪怕你把 ROUND 的参数写得再准，输入源是 FLOAT，结果就天然带不确定性。