MySQL 隐式替换导致精度丢失

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

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

执行SQL 1 :

查询结果 1 :

执行SQL 2 :

查询结果 2 :

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

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

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

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

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

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

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

MYSQL是硬盘，SQLITE是U盘，MongoDB是内存条

用途上，MYSQL和SQLITE是一样的。。都是用来存数据。。区别在于MYSQL需要启动后台服务，而SQLITE只需要一个文件，并不需要启动服务。。MYSQL的表空间的最大容量为64TB。。而整体容量几乎是无上限的，前提是你要有足够的硬盘空间。。而SQLITE的最大数据量，经过实际测试，大约在2TB左右。。

MYSQL只能部署在电脑上，而SQLITE既可以部署在电脑上，也可以用于手机等移动设备。。。但MYSQL支持的数据量比较大，SQLITE数据量小。。。这两个数据库对于数据储存都不够精确，小数点位数过多时，会丢失精度。一半用于互联网行业，做图文类网站。不能用于金融、财务、军事、科研、测绘等需要保证小数点精度的工作。更高端的数据库有SqlServer和ORACLE，这两个数据库则十分精确。

MongoDB是NOSQL数据库，这玩意和MYSQL,SQLITE不是一回事。。。里面其实是一大堆类似JSON的键值对。。。主要作用是作为临时储存，相当于变相起到了给关系型数据库加速的作用。。简单讲，它的作用主要用于加速，而并不是用于最终储存。。所以它是选配，并不是必须的。注意MongoDB有安全问题，非常容易攻击。若是有重要数据，最好别用。

---