ROUND函数不能解决财务精度问题，根本原因是浮点数无法精确表示十进制小数，必须全程使用DECIMAL类型并确保ROUND作用于精确值，否则会放大误差。
ROUND 函数本身不能解决财务报表的精度问题——它只是对已有数值做数学舍入，而财务误差的根源在数据类型和计算链路。
为什么 ROUND(amount, 2) 在财务场景下大概率出错？
常见现象：数据库里明明存了 12.345，但 ROUND(amount, 2) 返回 12.34 而不是 12.35。
- 根本原因不是函数 bug，而是字段类型为
FLOAT或DOUBLE：二进制浮点数无法精确表示十进制小数，12.345实际存储为12.344999999999999 -
ROUND拿到的是这个近似值，按规则向下舍入，结果自然偏差 - MySQL 5.7、旧版 PostgreSQL、SQL Server 的
money类型都存在类似风险
必须用 DECIMAL 配合 ROUND，且定义时机要早
关键不是“要不要用 ROUND”，而是“ROUND 作用的对象是否是精确十进制数”。
- 建表时就该定死：比如
ALTER TABLE invoices MODIFY amount DECIMAL(15,4)（中间计算留 4 位，展示再取 2 位） - 导入 CSV 时别用
CAST(@val AS FLOAT)，改用CAST(@val AS DECIMAL(15,4)) - 查询中写
ROUND(amount, 2)才真正安全——此时输入是精确的DECIMAL，不是浮点近似体 - Oracle 用户注意：
NUMBER类型天然安全，但若字段定义为NUMBER(10)（无小数位），后续ROUND(x, 2)会隐式转成浮点，仍可能失真
SUM(ROUND()) 和 ROUND(SUM()) 差 0.01 元？会计准则只认后者
明细行各自 ROUND(detail_amt, 2) 再加总，和先 SUM(detail_amt) 再 ROUND(..., 2)，结果常不一致——这不是 SQL 问题，是会计逻辑问题。
- 错误写法：
SUM(ROUND(amount, 2))→ 每行独立进位，误差叠加 - 正确写法：
ROUND(SUM(amount), 2)→ 总额控制，符合“所见即所得”要求 - 如需明细行显示分配后金额（比如分摊费用），得用补差算法：先算出总额
ROUND(SUM(amount), 2)，再按比例分配，最后一行填平差额 - SQL Server 用户额外注意：
ROUND默认是银行家舍入（2.5 → 2），财务场景需绕开：用FLOOR(amount * 100 + 0.5) / 100.0替代
ROUND 返回 13.150 而不是 13.15？这不是格式问题，是类型继承
ROUND 是数学函数，不负责格式化输出。它返回值的精度由输入字段类型决定。
- 如果原始字段是
DECIMAL(10,3)，ROUND(x, 2)结果仍是DECIMAL(10,3)，末尾零保留 - 前端或报表工具看到
13.150可能解析失败或自动补零，必须显式截断：CAST(ROUND(amount, 2) AS DECIMAL(10,2)) - MySQL 可用
CONVERT(DECIMAL(10,2), ROUND(amount, 2))；PostgreSQL 推荐ROUND(amount, 2)::DECIMAL(10,2) - 别指望
TO_CHAR或FORMAT解决根本问题——它们只管展示，不修复计算链路上的精度丢失
真正难的从来不是怎么写 ROUND，而是从数据入库那一刻起，就用 DECIMAL 切断浮点误差链；以及明确四舍五入该放在哪一层：计算层？展示层？还是导出前最终格式化？漏掉其中一环，ROUND 就成了误差放大器。
