ROUND(amount, 2)在财务场景危险，因float/double类型存储12.345实际为12.344999…，导致ROUND返回12.34而非12.35；须用DECIMAL类型配合ROUND，或采用ROUND(SUM())总额控制法避免累计误差。

ROUND 函数不能直接解决财务报表的精度问题，它只是把浮点数四舍五入成近似值——而财务计算必须用精确小数，否则累计误差会暴露在分位甚至角位。

ROUND(amount, 2) 为什么在财务场景下危险？

数据库里 amount 如果是 float 或 double 类型，比如存了 12.345，实际存储可能是 12.344999999999999；这时 ROUND(12.345, 2) 可能返回 12.34 而非预期的 12.35。这不是函数 bug，是二进制浮点数固有缺陷。

• 银行/会计系统要求“所见即所得”，必须按十进制规则逐位进位
• 报表中多个 ROUND 相加 ≠ 对总和做一次 ROUND，容易出现 0.01 元差异
• PostgreSQL 的 ROUND(numeric, s) 安全，但 MySQL 5.7 默认 ROUND(float, 2) 仍走浮点路径

真正该用 DECIMAL + ROUND 的组合方式

先确保字段类型是 DECIMAL(15,2)（或至少 DECIMAL(15,4) 用于中间计算），再用 ROUND。此时 ROUND 操作对象是精确十进制数，结果可预测。

• 建表时强制： ALTER TABLE financials MODIFY amount DECIMAL(15,4);
• 查询时四舍五入到分： SELECT ROUND(amount, 2) AS display_amount FROM financials;
• 若原始数据来自 CSV 导入，务必用 CAST(@amount AS DECIMAL(15,4)) 而非 CAST(@amount AS FLOAT)
• Oracle 用户注意：ROUND 对 NUMBER 安全，但 TO_CHAR(x, 'FM999999.00') 是更稳妥的展示层处理方式

遇到 SUM(ROUND(...)) 和 ROUND(SUM(...)) 不一致怎么办？

这是财务对账常见矛盾点：明细行各自四舍五入后加总，和先加总再四舍五入，结果可能差 0.01 元。会计准则通常要求后者（即“总额控制法”）。

• 错误写法：SUM(ROUND(detail_amt, 2)) → 各行独立进位，误差放大
• 正确写法：ROUND(SUM(detail_amt), 2) → 保持精度链完整
• 如需在明细行显示“分配后金额”，得用辅助算法：先算出 ROUND(SUM(detail_amt), 2) 总额，再按比例分配，最后一行补差
• SQL Server 用户注意：ROUND 默认使用“四舍六入五成双”，如需传统四舍五入，改用 ROUND(value + 0.0001, 2)（仅限正数）

财务系统的精度问题从来不在函数本身，而在数据类型的定义时机、输入源的转换逻辑、以及四舍五入该放在哪一层——计算层？展示层？还是导出前的最终格式化？漏掉其中一环，ROUND 就会变成误差放大器。