mysql关于数值精度问题

问题来源:

前几天用户向我反映了一个问题,有一个金额字段当输入到达百万级时,个位数的精度会丢失,即1000001会显示为100W,然后我就开始查找问题所在。

 

背景:

首先,实体类该字段为float类型,mysql类型也为float,然后当我在后台保存数据时:

假设金额nowPrice = 1008622java输出为:1008620,而mysql显示为:111007_86Io_1985414.png

显然是因为科学计数法把个位数的精度丢失了,从而导致数据出错。

 

问题分析过程:

一开始我认为是java问题,因为floatdouble类型当位数过多时会自动转化为科学计数法,可能在转换的过程中精度丢失了,从而导致数据库的数据出错。

为了验证以上说法,我使用sql查询语句来测试,结果:

111008_x60v_1985414.png 

111105_txq6_1985414.png 

即使用1008622作为条件可以正确查询到记录,而使用1008620是不能查询到记录的,因此我认为数据库的真实数据是正确的,但显示则使用丢失了精度的科学计数法。

 

然后我直接使用mysql驱动连接数据库并查询结果,发现ResultSet rs.getString("nowPrice") = 1.00862e+06rs.getFloat("nowPrice") = 1008620.0,可见mysql是把丢失了精度的科学计数法直接返回给应用。

至此可以确定是mysql的问题了,于是我查询了相关资料并请教公司DBA,原来floatdouble是属于非标准类型,他们在mysql中保存的是近似值,会导致精度问题。

之后我做了更多测试,包括添加小数点数值。当添加了小数点之后,基本上无法使用该字段作精确的条件查询出来了。

PS:可以使用此方法查出来:select * from tt_price where price = (select price from tt_price);

111008_UUr9_1985414.png 

总结float类型的问题:1.数值达到百万级别时真实数值与显示数值不一致;2.返回给应用的数值不是真实数值;3.小数点位数过多时会进行四舍五入,导致查询、更新操作出现异常情况。

类似的double类型同样存在以上的问题,只不过double是双精度,需要更高位数时才能出现这种问题。

 

结论:

因此,在比较敏感的字段上如金额等字段,建议使用:mysql使用decimal类型,oracle使用Number类型。Decimal是以字符串的形式保存数值,Number则是变长阿拉伯数字数组。两者均可以指定总位数和小数位,另外精度和小数位不会影响数据如何存储,只会影响允许哪些数值及数值如何舍入。

 

续篇:

后来经过测试,mysqlfloatdouble也可以指定总位数和小数位,显式地指定位数和小数位后效果与decimal无差,不会存上真实数值与显示数值不一致,因此float基本能满足我们的日常需求了,只是必须要指定位数而已。


转载于:https://my.oschina.net/u/1985414/blog/380343

<think>好的,我现在需要解决用户关于MySQL中SUM函数精度问题的疑问。首先,我应该回忆一下自己对SUM函数的了解,以及在使用过程中可能遇到的精度问题。 用户提到的是SUM函数的精度问题,这意味着在数值计算时可能会出现预期之外的结果,比如小数点后的精度丢失或者不准确。这可能涉及到数据类型的选择,比如使用浮点数类型(FLOAT、DOUBLE)和定点数类型(DECIMAL)的区别。因为浮点数是近似值存储,而DECIMAL是精确存储的,所以当对浮点数列进行SUM操作时,累积误差可能会更明显。 接下来,我需要验证这一点。例如,假设有一个表存储金额,如果使用DOUBLE类型,多次累加后可能会有微小的误差。而使用DECIMAL类型则可以避免这种情况。我应该构造一个例子来展示这两种情况的不同结果。 然后,用户可能想知道如何解决这个问题。解决方案应该是建议使用DECIMAL类型,并指定合适的精度和小数位数。此外,可能还需要提到在应用层进行四舍五入处理,或者在SQL查询中使用CAST函数转换数据类型以确保精度。 另外,还需要考虑版本差异,不同MySQL版本是否有改进。例如,某些版本可能在处理SUM时对DECIMAL有更好的优化,或者浮点数的处理是否有变化。但一般来说,数据类型的选择是关键因素。 还需要注意其他可能影响精度的因素,比如多次SUM操作后的结果累加,或者在JOIN、GROUP BY时的计算。可能还需要提到MySQL的文档中的相关说明,增强回答的可信度。 总结下来,回答的结构应该是先解释问题原因,再通过示例对比,最后给出解决方案和最佳实践。同时,要使用中文,保持口语化,避免使用Markdown格式,并确保数学公式的正确性(如果有的话)。</think>MySQL的`SUM()`函数在处理数值类型时确实存在精度问题,主要与数据类型的选择有关。以下是关键点分析: 1. **浮点数陷阱** 当对`FLOAT/DOUBLE`类型列求和时,由于浮点数的二进制存储特性,连续累加可能出现误差: ```sql CREATE TABLE test (num DOUBLE); INSERT INTO test VALUES (0.1), (0.1), (0.1); SELECT SUM(num) FROM test; -- 可能返回 0.30000000000000004 而非精确的0.3 ``` 2. **定点数解决方案** 使用`DECIMAL(M,D)`类型可确保精确计算(M是总位数,D是小数位): ```sql ALTER TABLE test MODIFY num DECIMAL(10,2); INSERT INTO test VALUES (0.1), (0.1), (0.1); SELECT SUM(num) FROM test; -- 精确返回0.30 ``` 3. **精度扩展现象** 即使使用DECIMAL类型,SUM()会自动扩展结果的小数位数: ```sql -- 原始数据:1.00, 1.000 SELECT SUM(num) FROM decimal_table; -- 结果小数位会扩展为3位 → 2.000 ``` 4. **最佳实践** ✓ 金额等敏感数据必须使用DECIMAL类型 ✓ 建表时明确指定精度:`DECIMAL(15,2)` ✓ 查询结果用`ROUND()`控制显示位数: ```sql SELECT ROUND(SUM(num), 2) AS total; ``` 5. **特殊情况处理** 当数值超过DECIMAL定义的精度时,不同版本处理方式不同: - MySQL 5.x 会截断数据 - MySQL 8.x 默认报错(可通过设置`@@sql_mode`调整) 建议:对于财务系统等精度敏感场景,应在数据库设计阶段就使用DECIMAL类型,并在应用层做二次精度校验。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值