结论是round函数最通用但跨库行为差异大：mysql/postgresql/sql server支持负精度和表达式参数，sqlite不支持负数需绕行；null输入返回null；decimal字段round后仍保持原精度类型；金额运算须用decimal防浮点误差。
SQL中ROUND函数的正确用法和常见误区
直接说结论：用 ROUND() 是最通用、最安全的方式，但不同数据库对小数位数为负数或NULL的处理差异很大，不加注意会导致结果意外截断或报错。
比如在MySQL里 ROUND(123.456, 2) 返回 123.46，但在SQL Server中如果字段是 DECIMAL(5,2) 类型，即使调用 ROUND(col, 2) 也不会改变显示精度——实际值虽已四舍五入，但查询结果仍按定义精度补零。
- Oracle默认会把
ROUND(123.456, -1)（即精确到十位）算成120，而PostgreSQL同样写法返回120.0，类型变成numeric - SQLite不支持负数精度，
ROUND(123.456, -1)会直接报错near "-1": syntax error - 所有数据库中，如果被四舍五入的字段本身为
NULL，ROUND(NULL, 2)结果仍是NULL，不会转成0或空字符串
不同数据库对ROUND参数的兼容性差异
核心问题不在函数名，而在第二个参数（小数位数）是否允许为负、是否支持表达式、是否强制要求整数类型。
例如想把金额字段 amount 统一按“百元”取整（即舍入到最近的100），应写成 ROUND(amount, -2)。但这个写法在SQLite中不可用，必须改用 ROUND(amount / 100) * 100。
- MySQL / PostgreSQL / SQL Server：支持负数，也支持列名或计算表达式作第二参数，如
ROUND(price, discount_level) - Oracle：第二参数必须是常量或绑定变量，不能是普通列名；且不支持浮点数，
ROUND(val, 1.5)会报错 - SQLite：只接受整数常量，不支持变量、列、负数；必须用除法+乘法绕过
ROUND与CAST/CONVERT混用时的隐式类型转换陷阱
很多人想“先四舍五入再转成整数”，于是写 CAST(ROUND(price, 0) AS INTEGER)，结果发现某些数据库（如PostgreSQL）中，ROUND(123.5, 0) 返回的是 numeric 类型，而 CAST(... AS INTEGER) 在遇到 .5 时可能触发银行家舍入（四舍六入五成双），导致 123.5 → 124，但 124.5 → 124。
- 明确要“传统四舍五入+转整”时，优先用
FLOOR(x + 0.5)（正数场景）或更稳妥的CASE WHEN x >= 0 THEN FLOOR(x + 0.5) ELSE CEIL(x - 0.5) END - SQL Server中
CONVERT(INT, ROUND(val, 0))和CAST(ROUND(val, 0) AS INT)行为一致，但若val超出INT范围，会在CAST阶段报错，而不是ROUND阶段 - 避免链式操作如
CAST(ROUND(CAST(val AS DECIMAL(10,4)), 2) AS FLOAT)—— 多次类型转换可能放大浮点误差
业务场景下该用ROUND还是应用层处理？
如果只是前端展示需要保留两位小数，别在SQL里硬ROUND；数据库负责存准，展示逻辑交给应用或视图层更可控。
真正该在SQL里用 ROUND() 的典型场景只有三个：聚合后精度归一（如 AVG(sales) ROUND(2)）、跨单位换算对齐（如把KB转MB后统一保留1位小数）、报表统计需满足审计要求的固定精度。
- 实时性要求高的接口，避免在WHERE或JOIN条件中用
ROUND(col, 2) = 12.34—— 这会阻止索引使用，改用范围查询：col BETWEEN 12.335 AND 12.345 - 涉及金额运算时，优先用定点数类型（
DECIMAL）而非FLOAT，否则ROUND(0.1 + 0.2, 1)可能得0.30000000000000004再ROUND成0.3，看起来对，实则底层已失真 - PostgreSQL用户注意：
ROUND(numeric)不带第二参数时默认为0，但ROUND(float8)默认行为是去小数位——类型不同，语义就不同
最易被忽略的一点：ROUND不是格式化函数。它改变数值本身，但不控制输出长度或补零。需要‘12.3’显示成‘12.30’，得靠应用层或数据库的TO_CHAR/FORMAT类函数，不是ROUND的事。
