ROUND()函数在不同数据库中舍入策略不一致：Oracle和PostgreSQL用银行家舍入，金仓和MySQL多用四舍五入，导致跨库对账偏差；需逐笔舍入再聚合、显式处理NULL与类型转换，并在ETL层固化规则。
ROUND() 在不同数据库中行为不一致
财务对账差异最常出现在迁移或跨库查询场景里。ROUND() 函数在 Oracle、金仓、PostgreSQL、MySQL 中默认舍入策略不同：Oracle 和 PostgreSQL 默认用“银行家舍入”（四舍六入五成双），而金仓、MySQL 多数版本用传统四舍五入。比如 ROUND(2.5, 0) 在 Oracle 返回 2，在金仓返回 3；ROUND(3.5, 0) 同理。单次差异虽小，但百万级交易汇总后，偏差可达数千元——某农信社就因此触发风控熔断。
聚合前未控制中间精度，误差被放大
财务金额计算不能只在最终结果上 ROUND()，否则 SUM 内部保留过多浮点位，会累积不可控偏差。错误写法：SUM(unit_price * quantity * (1 - discount_rate))；正确做法是逐笔先舍入再聚合：SUM(ROUND(unit_price * quantity * (1 - discount_rate), 2))，最后再整体 ROUND(..., 2)。否则即使所有明细四舍五入到分，SUM 仍可能因浮点运算多出 0.01 元。
GROUP BY + ROUND() 导致明细与合计不等
这是报表“合计不等于明细加总”的直接原因。例如三笔金额为 123.45、234.56、345.67 的记录，分别 ROUND(x, 0) 得到 123、235、346，合计 704；但实际总和 703.68 四舍五入也应为 704 —— 表面一致，实则掩盖了 0.32 元的累计误差。更危险的是，若业务要求按明细舍入后求和，而系统按原始值求和再舍入，两者结果可能不一致，审计时无法追溯。
没处理 NULL 或隐式类型转换干扰聚合
SUM() 和 ROUND() 遇到 NULL 会跳过，但若字段本应为数值却存了空字符串或非法字符（如 '100.50a'），某些数据库会静默转为 0 或报错，导致结果偏低或中断。尤其在进销存对账中，采购单含空折扣率、销售单缺税率字段，都会让 ROUND(SUM(...), 2) 输出失真。建议前置用 COALESCE(列, 0) 和 CAST(列 AS NUMERIC(18,2)) 显式约束类型与空值。
真正难处理的不是单次 ROUND，而是它嵌套在聚合、JOIN、子查询中的多层精度传递。一旦底层数据源舍入规则不统一，上层再怎么校验都只是补漏。最稳妥的做法，是在 ETL 或视图层就固化舍入逻辑，并在关键字段加注释说明所用规则（比如 “按银行家舍入保留两位小数”），避免后续开发误以为是“标准四舍五入”。
