MySQL运算中遇到的怪问题

Posted 2023-05-17

现有y2p和EURGBP两个表。两表结构均为 date（DATE型）, time（TIME型）, money（DOUBLE型） 三列，除money数值不同外，date和time完全一样。

我用如下SQL语句抽取两表中的money值，和它们相减后的结果。

select
t1.money as 1st,
t2.money as 2nd,
(t1.money - t2.money) as 3rd
from EURGBP t1
inner join y2p t2
on t1.date = t2.date
and t1.time = t2.time
where t1.date = '11/6/7' and t1.time = '23:56';

得出的值如下：1st为0.89296，2nd为0.89288， 3rd为7.9999999999969e-05
也就是说，3rd的运算结果不符合预期。（其实也不完全是不相干的数，因为7.9999999999969e-05无限接近于预期值0.00008中的8）

单独输入select 0.89296-0.89288，则显示结果为0.00008，符合预期。

我SQL基础不太好，百思不得其解，望指教！

mysql 本身这种数据库就有一定的模糊性。而且我没发现没有什么数据类型窥探的API。
--------------------------------------------------------------------------------------------------------------
select 0.89296-0.89288
以上这种是作为变长数据进行处理的。
如果你不信就设计一个表，用varchar存数字，用他们来计算，基本没有舍入误差，理由很简单，那是变长数据。
-----------------------------------------------------------------
select
t1.money as 1st,
t2.money as 2nd,
(t1.money - t2.money) as 3rd
from EURGBP t1
inner join y2p t2
on t1.date = t2.date
and t1.time = t2.time
where t1.date = '11/6/7' and t1.time = '23:56';
----
如果那个sql是以double进行运算，而double[n] 这种是定长数据，如果在有限的8字节存储空间中进行大范围存储，高精度是不可能的，它采用的科学计数法存储方式。
科学计数法采用的是有效数字。而不是高精度类型
---------
总结：你可以认为select 0.89296-0.89288 这种方式采用的是变长DECIMAL(M,D)进行运算。
DECIMAL属于高精度类型。
而你的sql是采用double进行的科学计数法运算。
--------
Look at: DECIMAL在mysql中是变长数据类型。
-----
LZ水平不错，入我团队吧！----> 数据库聚贤庄 O(∩_∩)O哈哈~ 参考技术A 靠，楼主这个问题深了，你这个 elect 0.89296-0.89288是把你那个东西默认堪称float类型，而你用两个字段相减是默认成double类型，因此是这个结果，其实结果是一样的，只是小数位是一样的，只是机器的敏感度不一样

空格变成问号的怪问题

最近做项目遇到了这个问题，在网上找了一下解决方法，发现这篇文章也是转载的，不过，他没有标出原出处，我在网上查找了一会，没有找到更多的，或者找到的都是别这个还要晚的文章，那么我标明的出处就算这个吧http://blog.csdn.net/wuhongyao3/article/details/5834921

 

文章：

昨天发现，用 HtmlDecode（） 去解码后，“ ”不是被解码为半角的空格（ASCII码0x20）而是变成半角问号“?”（ASCII码0x3F）。而且奇怪的是，只有每行前面的空格才会出问题，如果前面后面有汉字的话，空格就还是空格。但是更加奇怪的是，如果直接在HtmlDecode()的后面直接加上trim()的话，这个问号会被去掉。而正常的情况下，问号是不会被去掉的，只有空格才会被去掉。

发生这个问题的时候，我是在把解码后的内容写入数据库，因此一直都以为是sqlserver与应用程序之间的字符集问题或者编码方式问题。搞了N久，最后才发现在送进SqlServer之前，内容就已经是问号了。

查了很久，也找不到这个问题如何解决。因此，只能使用山寨解决方法了：

1、在Decode之前替换   为 空格。

2、在Decode之后直接加 Trim()

显而易见的，这个不是一个好办法：在显示到浏览器的时候，空格就不见了

最近认真去查了一下这个问题，发现问题的关键，是编码方式：如果使用的Encoding是UTF-8的话，就会发生这种情况。

问题的根源，在于UTF-8这种编码里面，存在一个特殊的字符，其编码是“0xC2 0xA0”，转换成字符的时候，表现为一个空格，跟一般的半角空格（ASCII 0x20）一样，唯一的不同是它的宽度不会被压缩，因此比较多的被用于网页排版（如首行缩进之类）。而其他的编码方式如GB2312、Unicode之类并没有这样的字符，因此如果简单地进行编码转换，生成地GB2312/Unocode字符串中，这个字符就会被替换成为问号（ASCII ox3F）。此时如果进行写库、写文件之类，就会把问号直接写入了。当然此时会有一种山寨方式：直接替换问号为空格。可是这种方法，会把原本真正的问号也枪毙掉。

使用UTF-8进行HTMLDecode的时候，对于语句开头的（ ），就会被自动转换成为这个特殊的空格，可能是判断为放在开头的空格，一定是用来排版的。在转换为其他编码之前，这个特殊的空格受到的待遇与普通的半角空格是一致的，甚至也会被trim()去掉。

因此，碰到这个问题的原因有两种：一种是在UTF-8编码下进行了转换，产生了这个字符；还有一种就是网页中直接采用了这个字符进行排版。

知道了具体原因，就有正规的解决方法了。方法就是：在得到UTF-8字符串之后，先进行一个替换，把这个特殊的空格替换为普通的空格，如果是HTML串，建议替换为（ ）。C#代码如下：

byte[] space = new byte[]{0xc2,0xa0};
string UTFSpace = Encoding.GetEncoding("UTF-8").GetString(space);
HtmlStr = HtmlStr.Replace(UTFSpace," ");
这样做，就不会把串里面本来应该有的问号错误的替换为空格。也不会看到讨厌的问号，能保存原来字符串的真面目了。
需要强调的是，替换之前不能进行编码转换，一定要继续使用UTF-8编码。如果已经转换成其他编码，那么错误就已经不可逆转了。没有办法再区分这个错误的问号和正常的问号之间的差别了。