DB2中DECIMAL类型转换精度异常问题求助：将小数转换为指定精度DECIMAL时出现偏差

嘿，这个问题我之前也踩过，核心就是二进制浮点数的精度误差在搞鬼，咱们来捋清楚：

为啥25.555转出来变成25.554999？ #

你输入的25.555看起来是个普通小数，但在计算机里，大部分十进制小数没法用二进制浮点数精确存储——二进制只能精准表示分母是2的幂的分数（比如0.5、0.25），但25.555拆成分数是5111/200，分母里有5这个因子，所以存储的时候是一个非常接近25.555但略小的近似值。当你用CAST转成DEC(9,6)时，这个近似值就被“打回原形”，变成了25.554999。

至于16.667能正常转换，纯粹是运气好——它的二进制近似值刚好够接近16.667，转DEC的时候被正确舍入到了16.667000，但这不是常态哦。

给你几个靠谱的解决办法 #

1. 直接用字符串转DEC（最稳妥） #

如果你的数值是从字符串来源获取的（比如用户输入、文本文件），别先转成浮点数，直接用字符串转DEC：

CAST('25.555' AS DEC(9,6))

这样数据库会直接按十进制规则解析，完全避开浮点数的精度坑。

2. 先转整数再还原 #

把小数放大成整数，绕开浮点数误差：

CAST(ROUND(25.555 * 1000, 0) / 1000 AS DEC(9,6))

这里ROUND确保25.555*1000得到精确的5111（不会是5110.999999...），再除以1000就得到精准的25.555，转DEC后自然就是25.555000。

3. 从源头用高精度类型 #

如果你的数据库支持（比如SQL Server的NUMERIC、PostgreSQL的DECIMAL），别用FLOAT这类浮点数类型存数值，直接用DEC/NUMERIC类型，从一开始就避免精度损失。

额外提一句你说的DEC范围 #

你提到DEC的第一个参数（总位数）范围是1到3？这有点奇怪啊，标准SQL里DEC(p,s)的p（精度）可以到38呢。如果是你用的数据库有特殊限制，那要注意：25.555000总共有7位（2位整数+6位小数），如果p只能到3的话，DEC(3,6)是无效的——小数位数不能超过总位数，这时候要么调整小数位数，要么确认下数据库的DEC类型定义是不是理解错了。

内容的提问来源于stack exchange，提问作者Div