MySQL 隐式替换导致精度丢失

原来只知道, MySQL类型隐式替换会影响优化器对索引的选择, 由于遇到了一个隐式替换导致的精度丢失的 Bug ,引起了我对隐式替换的实现逻辑的好奇心.

为什么隐式替换会影响精度吗? 不是类似 String.valueOf() 处理吗?

执行SQL 1 :

查询结果 1 :

执行SQL 2 :

查询结果 2 :

由上面的两个SQL看到, 由于where条件的业务订单id筛选项没有添加引号, 导致了精度丢失问题. 210517130303013756 在表中是唯一的, 但是查出来多条数据.

如需构建演示环境请执行如下SQL

这里贴出了数字类型相关的替换规则, 想了解更多请查阅官方文档

有关隐式数字到字符串转换的字符集以及适用于 CREATE TABLE ... SELECT 语句的修改规则，请参阅本节后面的信息。

以下规则描述了比较 *** 作如何发生转换：

有关将值从一种时间类型转换为另一种时间类型的信息，请参见 第11.2.8节“日期和时间类型之间的转换” 。

由于 210517130303013756 没有加引号, 默认将其作为浮点数处理, 所以在 210517130303013756 转浮点数的时候, 导致了精度丢失问题.

一个查询 *** 作，不管表里有没有数据，只要语句执行成功都是返回0，查到0条数据也是返回0，返回0表示语句执行成功。

参考：https://dev.mysql.com/doc/refman/5.7/en/mysql-store-result.html

你需要再调用mysql_store_result和mysql_num_rows来得到查询到的记录条数。

谈谈个人理解，请带着怀疑和鉴别的角度去看待。

1 先理解下定点数

--定义：

指规定小数点位置固定不变。

--存储：

* 在数据库或计算机中存储时，整数部分和小数部分分别使用一定的字节来存储（理解为分别用两部分字节来存储两个整数），小数点是作为存储属性存储的（如作为列类型时，小数点位置存储在表的定义部分），而不占用数据的存储字节。

* 定点数使用多少字节来存放数据，依赖于该数指定的精度（精度即为该数的总数字位数），总数字位数为小于2则使用1字节，为5-9位时用4字节，为19-38位时使用16字节（大部分数据库支持的最大就是38位数字）；

--举例：

numeric(2,1)，精度为2，使用1个字节来存放，存放数据范围为[-9.9, 9.9]；如存储2.3时，在数据库存储为00100011，而小数位置固定在第四位前，这是由定义列时指明的；

--说明：

定点数存储精确的数字，numeric(2,1)就只能[-9.9, 9.9]之间的数，存的不是近似数（因为两部分都作为整数存储）；当你在numeric(2,1)中存储2.33时，实际发生了隐式转换，实际存储为9.3（注意这并不是近似）；

2 再来理解浮点数

--定义：

指采用浮点数表达方式来表示数据，这种表达方式利用科学计数法来表达实数，即用一个尾数（Mantissa ），一个基数（Base），一个指数（Exponent）以及一个表示正负的符号来表达数据，比如 123.45 用十进制科学计数法可以表达为 1.2345 × 10^2，其中 1.2345 为尾数，10 为基数，2 为指数。称其为浮点数就是因为利用指数达到了浮动小数点的效果。

--存储：

浮点数一般是使用IEEE规定的方式，即 对于单精度浮点数用1bit来存储符号位（正负号），8bit来存储指数，23bit来存储尾数；而且要求尾数的整数部分为1（注意，指二进位格式的，如1.01001），而且是使用二进位来保存，即基数为2；

在大多数数据库或计算机中存储时，单精度使用4字节，双精度使用8字节保存；

--举例：

二进制的 1001.101（对应于十进制的 9.625）可以表达为 1.001101 × 2^3，存储时符号位+存储为0，指数3存储为00000011，尾数1.001101存储为0011010000..（总共23位，去掉了小数点前的1，IEEE就是这样要求的）；

--近似的产生：

因为我们使用的是十进制数，而计算机要转换为对应的二进制形式，由于有限的2进制位数表示的小数值不能和十进制一一对应（换句话说，十进制小数转为二进制可能变为无限小数而导致不精确 ），如2^-1对应0.5，2^-2对应0.25，2^-3对应0.125，因此对于像十进制的0.4（小数的末尾一位数不为5的）则不能精确存储；

--因近似引起的问题：

create table t (a float, b float)insert into t values(0.11, 0.04), (0.04, 0.11)

select * from t查询时显示正常，实际底层存储时发生了近似（十进制转换为二进制），而显示时又发生了近似（二进制转换为十进制）；

select sum(a) from t查询显示 0.14999999850988388 ，为什么不是0.15的原因也就不言而喻了。

这也就是浮点数在损失精度、计算和比较要格外注意的事项；

3 总结

定点数，能存储精确数字，但保存的数据范围受了严格限制，格式也比较僵硬（这既是好处，也是坏处）；

浮点数，不能存储精确数字，在小数的末尾一位数不是5（一直乘2不能圆整）的情况下会发生存储的近似处理；但可存储的数据范围更大；

---