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 就会变成误差放大器。
