SQL Server float uncertainty
Most of the time, we all know that the floating point storage is an uncertain value, and you will never know whether it is something like 0 = 0.00000000000000123 or 0 = 0.00000000000999. There may be no problems at the beginning, but sometimes we can see the clues when making statistics.
A simple example shows that unexpected results may occur during statistics. As a result, the stored procedure or the recipient's code may need to be processed by an additional number on the left, so here I actually recommend using Numeric to replace float for an alternative, avoid a sum, and then clearly show that each piece of data is a normal 2, 3 decimal places, A summary turns into 8 to 9 digits.
Create table # T (id int identity, Va FLOAT) create table # T1 (id int identity, Va NUMERIC (15, 9) -- run separately ------------------------------------------------- insert into # T (Va) VALUES (0.60000000) insert into # T1 (Va) VALUES (0.60000000) GO 100 select sum (Va) FROM # tselect sum (Va) FROM # T1----------------------60.0000000000001 (1 line affected) --------------------------------------- 60.000000000 (1 line is affected)
Summary
The above is all about the uncertainty of float under sqlserver. I hope it will be helpful to you. Interested friends can refer to this site: brief the difference between Redis and MySQL, analysis of technical points of oracle SQL statement optimization, analysis of MYSQL subqueries and nested query optimization instances, etc, if you have any questions, you can leave a message at any time. The editor will reply to you in a timely manner. Thank you for your support!