无法在mysql-workbench中将表字段从float更改为十进制

时间:2018-09-29 10:13:53

标签: mysql database decimal mysql-workbench alter

我创建了一个带有FLOAT类型列的表。但是,我发现在查询列的MAXMINAVG值时,我得到的数字不准确,其中返回的值大于表中实际存储的值。例如,这是表中的实际最大数字:0.00348675。 MAX以某种方式返回此:0.0034867459908127785

不准确的原因是由于选择FLOAT作为类型。因此,我想将列类型更改为DECIMAL.

我在Ubuntu 18中使用mysql-workbench。当我右键单击表并选择Alter Table时,可以更改数据类型。不幸的是,当我将相关字段从FLOAT更改为DECIMAL时,FLOAT会自动再次返回。由于某些原因,工作台无法选择DECIMAL。看到这张照片。我可以从列表中选择DECIMAL。然后,当我将鼠标移到其他位置以单击下一个空行时,可以单击ApplyDECIMAL消失,FLOAT再次返回:

enter image description here 谁能告诉我出现问题的原因是什么?如何克服这个问题?

1 个答案:

答案 0 :(得分:0)

FLOATDOUBLE以二进制而不是十进制编码。因此,大多数小数在存储时无法准确表示。 (以.5,.25,.75,.125等结尾的数字)可以完全存储,因为它们涉及2的幂。

FLOAT可以很好地大约 7个有效数字; DOUBLE到大约16。

0.00348675              You stored this decimal
0.003486746000000096    After conversion to binary, then back to decimal
0.0034867459908127785   See below

(我怀疑您实际上存储了0.003486756。)

某些计算是在DOUBLE中完成的;我怀疑MAX()会这样做。这涉及将FLOAT转换为DOUBLE。在此转换中,没有任何损失

好的,我不知所措地完成了解释。

只需说一遍-每当使用FLOATDOUBLE时,请注意,算术和显示都有这样的怪癖。

在某些情况下,MySQL尝试通过使用DECIMAL来避免此类问题。我会猜测,这里涉及某种方式,因为上面的中间数字大约有14个有效数字而不是16个数字,这意味着除了DOUBLE以外还涉及其他内容- -也许DECIMAL(..., 16)。注意:这是小数位,与有效位数_不同。

如果您想进一步进行此操作,请在http://bugs.mysql.com处提交的错误中提供简短的测试案例,并在此处将类似内容发布到此处。