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，结果就天然带不确定性。
