mysql float 的坑谁遇到过
| 字段 | 类型 | 长度 | 小数点 |
|---|---|---|---|
| test | float | 11 | 2 |
INSERT INTO dept ( test )
VALUES
( 140000.1 );
结果 140000.09
测试 130000.1 是好用的 感觉是float存储或是损失精度造成的，但不知道具体原因
找到临界点了 131071.10 可以 131072.10 就变成131072.09了
关于 LearnKu
粤公网安备 44030502004330号
改成string 模型set弄好小数点即可
IEEE 浮点数编码是一个很大的议题，IEEE 规定使用 (-1)^s×M×2^E 这个公式来表示浮点数。这里假设是单精度，即用 32 个 bit 来编码。其中：
所以，不可能用有限的位数来编码无限多的数字。如果一个有理数能够写成 a×2^b 这样的形式，例如 0.875 可以写成 1.75×2^(-1)，就能够被”准确的”编码(只要不超过表示范围)。其他的当然也能够被编码，但是超过 32 bit 的就要被截断。在支持 IEEE 浮点数的电脑上，截断采用的是向偶数进位的方式。
所以，如果你要存入的数，刚好能够被表示为 a×2^b 这样的形式，则这个数就会被正确的存入。反之就要被按照向偶数进位的方式进行近似，有的近似出来的刚好就是想要存入的，有的近似出来的和想要存入的就有误差。
不单单是 131072.10 会被”近似”错，131072.26 也会被”近似”错。这样的数有无穷多个。
同，遇到这个坑。就像楼上的老哥说的，不能用有限位数存大于这个位数的小数，例如mysql我定义了一个字段amount，l类型为decimal，长度为（20，3），现在有一个数12.1234，那么最终存入数据库的只有12.123。 但是如果涉及到钱(定长)，就必须要用decimal，因为钱（RMB）在接入支付后最小的单位是1分，换算成“元”，就是小数0.01，那么decimal就应该定义为(n,2)或者(n,3)。涉及到钱的，建议使用如果使用decimal存储。其他根据实际情况使用，或者对小数进行处理后保存。 但是，就算是使用String类型，也有可能出现在前端渲染的时候出问题，例如总数是13.1，就有可能显示为：12.09999998。
一般都用double；涉及金钱都用decimal
金钱的直接用int 单位默认分
不要用float用decimal
不要用 float 用 decimal