ROUND函数本身不丢失精度，但输入值已因FLOAT/DOUBLE类型失真；必须从建表起使用DECIMAL类型，确保ROUND作用于精确十进制数，否则误差不可控。
ROUND函数本身不丢失精度，但输入值已经失真
MySQL的ROUND函数没有bug，它只是忠实地对传入的数值做数学舍入。问题出在“传给它的那个数”早就不是你认为的那个数了。比如字段类型是DOUBLE，存0.1实际是0.10000000149011611938；算0.1 + 0.2得到的也不是0.3，而是0.30000000000000004。ROUND拿到这个近似值再四舍五入，结果自然偏差。
常见错误现象：
-
ROUND(100 * 1.005, 0)返回100而不是101（因为1.005作为FLOAT存储后实际是1.0049999999999999） -
SELECT ROUND('1.125', 2)得1.12——字符串参与运算触发“四舍六入五成双”，不是四舍五入
DECIMAL才是财务和精确计算的唯一安全类型
必须从源头控制：建表时就用DECIMAL(M,D)，别等查询时再补救。FLOAT/DOUBLE在MySQL里就是为科学计算设计的，不是为钱服务的。
实操建议：
- 建表定义金额字段：例如
amount DECIMAL(15,4)（中间计算留4位，展示时再ROUND(,2)） - 导入CSV时，用
CAST(@val AS DECIMAL(15,4))，禁用CAST(@val AS FLOAT) - 函数内声明变量也必须是
DECIMAL，比如DECLARE total DECIMAL(15,4) DEFAULT 0;，不能写FLOAT或DOUBLE - 调用自定义函数时，传参写
100.0而非100，避免隐式转DOUBLE
ROUND(SUM()) ≠ SUM(ROUND())，会计逻辑不能靠SQL自动推导
这不是精度问题，是业务规则问题。明细行各自ROUND(amount, 2)再求和，和先SUM(amount)再ROUND(,2)，结果常差几分钱。会计准则只认后者——总额控制，误差不放大。
容易踩的坑：
- 错误写法：
SUM(ROUND(detail_amt, 2))→ 每行独立进位，误差叠加 - 正确写法：
ROUND(SUM(detail_amt), 2)→ 符合“所见即所得”原则 - 若需明细显示分摊后金额（如费用分摊），必须用补差算法：先算总额
ROUND(SUM(),2)，再按比例分配，最后一行填平差额
ROUND返回值类型继承输入，末尾零不自动截断
ROUND是数学函数，不是格式化工具。它返回值的精度由输入字段类型决定，不会帮你“美化输出”。比如原始字段是DECIMAL(10,3)，ROUND(x, 2)结果仍是DECIMAL(10,3)，可能返回13.150而非13.15。
前端或报表工具看到13.150可能解析失败，必须显式截断：
- MySQL：
CONVERT(DECIMAL(10,2), ROUND(amount, 2)) - PostgreSQL：
ROUND(amount, 2)::DECIMAL(10,2) - 别依赖
ROUND自动“变类型”，它只算，不管输出长什么样
关键点始终落在数据类型的定义时机上——不是ROUND怎么用，而是ROUND作用的对象是否从一开始就是精确的十进制数。任何试图在浮点链路上打补丁的做法，都只是把误差往后推了一步。
