What difference does it make when I use float and decimal data types in MySQL?.
在MySQL中使用float和decimal数据类型时，会有什么不同?
When should I use which?
我应该什么时候使用它?
13 个解决方案
#1
169
This is what I found when I had this doubt.
这是我在怀疑的时候发现的。
mysql> create table numbers (a decimal(10,2), b float);
mysql> insert into numbers values (100, 100);
mysql> select @a := (a/3), @b := (b/3), @a * 3, @b * 3 from numbers \G
*************************** 1. row ***************************
@a := (a/3): 33.333333333
@b := (b/3): 33.333333333333
@a + @a + @a: 99.999999999000000000000000000000
@b + @b + @b: 100
The decimal did exactly what's supposed to do on this cases, it truncated the rest, thus losing the 1/3 part.
小数点在这种情况下做了正确的事情，它截断了剩下的部分，从而失去了1/3部分。
So for sums the decimal is better, but for divisions the float is better, up to some point, of course. I mean, using DECIMAL will not give you a "fail proof arithmetic" in any means.
因此，对于加法，小数是更好的，但对于划分，浮动是更好的，当然，在某种程度上。我的意思是，使用十进制不会给你一个“fail proof算术”。
Hope this helps.
希望这个有帮助。
#2
70
A "float" in most environments is a binary floating-point type. It can accurately store base-2 values (to a certain point), but cannot accurately store many base-10 (decimal) values. Floats are most appropriate for scientific calculations. They're not appropriate for most business-oriented math, and inappropriate use of floats will bite you. Many decimal values can't be exactly represented in base-2. 0.1 can't, for instance, and so you see strange results like 1.0 - 0.1 = 0.8999999.
在大多数环境中，“浮动”是二进制浮点类型。它可以准确地存储base-2值(到某个点)，但不能准确存储许多base-10 (decimal)值。浮动最适合科学计算。它们不适合大多数以业务为导向的数学，不恰当地使用浮动将会影响你。在base-2中不能精确地表示许多十进制值。例如，0.1不能，所以你会看到一些奇怪的结果，比如1.0 - 0.1 = 0.8999999。
Decimals store base-10 numbers. Decimal is an good type for most business math (but any built-in "money" type is more appropriate for financial calculations), where the range of values exceeds that provided by integer types, and fractional values are needed. Decimals, as the name implies, are designed for base-10 numbers - they can accurately store decimal values (again, to a certain point).
小数商店八进制数数数。对于大多数业务数学来说，十进制是一种很好的类型(但是任何内置的“货币”类型更适合于财务计算)，在这里，值的范围超过了整数类型提供的值，并且需要分数值。小数，顾名思义，是为基数10的数字设计的——它们可以精确地存储十进制值(再一次，到某个点)。
#3
21
MySQL recently changed they way they store the DECIMAL type. In the past they stored the characters (or nybbles) for each digit comprising an ASCII (or nybble) representation of a number - vs - a two's complement integer, or some derivative thereof.
MySQL最近改变了他们存储十进制的方式。在过去，他们将字符(或nybbles)存储为一个数字- vs的一个ASCII(或nybble)表示形式——一个二进制的补体整数，或其中的一些导数。
The current storage format for DECIMAL is a series of 1,2,3,or 4-byte integers whose bits are concatenated to create a two's complement number with an implied decimal point, defined by you, and stored in the DB schema when you declare the column and specify it's DECIMAL size and decimal point position.
目前的十进制存储格式是一系列的1,2,3,或4字节整数的位连接创建一个二进制补码数隐含小数点,由你定义的,并存储在DB模式当你声明列和指定的小数大小和小数点的位置。
By way of example, if you take a 32-bit int you can store any number from 0 - 4,294,967,295. That will only reliably cover 999,999,999, so if you threw out 2 bits and used (1<<30 -1) you'd give up nothing. Covering all 9-digit numbers with only 4 bytes is more efficient than covering 4 digits in 32 bits using 4 ASCII characters, or 8 nybble digits. (a nybble is 4-bits, allowing values 0-15, more than is needed for 0-9, but you can't eliminate that waste by going to 3 bits, because that only covers values 0-7)
举例来说，如果您使用一个32位的整数，您可以从0 - 4,294,967,295中存储任何数字。这只会可靠地覆盖999,999,999，所以如果你抛出2位，并且使用(1<<30 -1)，你将放弃任何东西。覆盖所有9位数字，只有4个字节，比用4个ASCII字符或8个nybble数字覆盖32位的4位数字更有效。(nybble是4位，允许0-15的值，比0-9需要更多，但是你不能把这些浪费掉到3位，因为这只包含0-7的值)
The example used on the MySQL online docs uses DECIMAL(18,9) as an example. This is 9 digits ahead of and 9 digits behind the implied decimal point, which as explained above requires the following storage.
在MySQL在线文档中使用的示例使用十进制(18,9)作为示例。这是9位数字，在隐含小数点后面9位，如上所述，需要以下存储。
As 18 8-bit chars: 144 bits
18 -位字符:144位。
As 18 4-bit nybbles: 72 bits
有18个4位的小石子:72位。
As 2 32-bit integers: 64 bits
作为两个32位整数:64位。
Currently DECIMAL supports a max of 65 digits, as DECIMAL(M,D) where the largest value for M allowed is 65, and the largest value of D allowed is 30.
目前，十进制支持最大的65位数字，如十进制(M,D)，其中M允许的最大值是65，允许的最大值是30。
So as not to require chunks of 9 digits at a time, integers smaller than 32-bits are used to add digits using 1,2 and 3 byte integers. For some reason that defies logic, signed, instead of unsigned ints were used, and in so doing, 1 bit gets thrown out, resulting in the following storage capabilities. For 1,2 and 4 byte ints the lost bit doesn't matter, but for the 3-byte int it's a disaster because an entire digit is lost due to the loss of that single bit.
因此，为了不需要一次使用9个数字块，可以使用小于32位的整数来使用1、2和3字节整数添加数字。由于某些原因，使用的是不符合逻辑的，而不是使用未签名的ints，这样做时，1位被抛出，导致了以下存储能力。对于1、2和4字节的字节来说，丢失的比特并不重要，但是对于3字节的整数来说，这是一场灾难，因为丢失了这一比特位就丢失了整个数字。
With an 7-bit int: 0 - 99
以7位整数:0 - 99。
With a 15-bit int: 0 - 9,999
有15位整数:0 - 99999。
With a 23-bit int: 0 - 999,999 (0 - 9,999,999 with a 24-bit int)
有一个23位整数:0 - 999,999(0 - 9,999,999和24位整数)
1,2,3 and 4-byte integers are concatenated together to form a "bit pool" DECIMAL uses to represent the number precisely as a two's complement integer. The decimal point is NOT stored, it is implied.
1、2、3和4字节的整数被连接在一起，形成一个“位池”小数，用来表示精确的数字作为一个2的补体整数。它是隐式的，不存储小数点。
This means that no ASCII to int conversions are required of the DB engine to convert the "number" into something the CPU recognizes as a number. No rounding, no conversion errors, it's a real number the CPU can manipulate.
这意味着，对于DB引擎来说，不需要使用任何ASCII来转换“数字”，从而将“数字”转换成CPU能够识别的数字。没有四舍五入，没有转换错误，这是CPU可以操作的实数。
Calculations on this arbitrarily large integer must be done in software, as there is no hardware support for this kind of number, but these libraries are very old and highly optimized, having been written 50 years ago to support IBM 370 Fortran arbitrary precision floating point data. They're still a lot slower than fixed-sized integer algebra done with CPU integer hardware, or floating point calculations done on the FPU.
对于这个任意大的整数的计算必须在软件中进行，因为对于这种数字没有硬件支持，但是这些库是非常古老和高度优化的，已经在50年前编写，以支持IBM 370 Fortran任意精度浮点数据。它们仍然比用CPU整数硬件完成的固定大小的整数代数慢得多，或者在FPU上做浮点运算。
In terms of storage efficiency, because the exponent of a float is attached to each and every float, specifying implicitly where the decimal point is, it is massively redundant, and therefore inefficient for DB work. In a DB you already know where the decimal point is to go up front, and every row in the table that has a value for a DECIMAL column need only look at the 1 & only specification of where that decimal point is to be placed, stored in the schema as the arguments to a DECIMAL(M,D) as the implication of the M and the D values.
在存储效率方面，因为浮点数的指数是附加在每个浮点数上的，它隐含地指定小数点的位置，因此它是大量冗余的，因此对DB的工作效率很低。在DB你已经知道小数点在哪里去,和表中的每一行一个十进制值列只需要看1 &只有规范的小数点是被放置的地方,作为一个十进制的参数存储模式中(M,D)的含义M和D值。
The many remarks found here about which format is to be used for various kinds of applications are correct, so I won't belabor the point. I took the time to write this here because whoever is maintaining the linked MySQL online documentation doesn't understand any of the above and after rounds of increasingly frustrating attempts to explain it to them I gave up. A good indication of how poorly they understood what they were writing is the very muddled and almost indecipherable presentation of the subject matter.
这里发现的关于各种应用程序的格式是正确的，所以我不赘述。我花了时间在这里写这篇文章，因为不管谁在维护这个链接的MySQL在线文档，我都不理解上面的任何内容，并且在不断地尝试向他们解释我放弃的时候，我也不明白。一个很好的迹象表明，他们对所写内容的理解是多么的糟糕，这是一个非常混乱和几乎无法解释的主题。
As a final thought, if you have need of high-precision floating point computation, there've been tremendous advances in floating point code in the last 20 years, and hardware support for 96-bit and Quadruple Precision float are right around the corner, but there are good arbitrary precision libraries out there if manipulation of the stored value is important.
最后认为,如果你有需要高精度的浮点计算,浮点代码中有巨大的进步在过去的20年里,和硬件支持96位和四精密浮动右拐角处,但是有好的高精度库如果操纵存储的值是很重要的。
#4
13
Not just specific to MySQL, the difference between float and decimal types is the way that they represent fractional values. Floating point types represent fractions in binary, which can only represent values as {m*2^n | m, n Integers} . values such as 1/5 cannot be precisely represented (without round off error). Decimal numbers are similarly limited, but represent numbers like {m*10^n | m, n Integers}. Decimals still cannot represent numbers like 1/3, but it is often the case in many common fields, like finance, that the expectation is that certain decimal fractions can always be expressed without loss of fidelity. Since a decimal number can represent a value like $0.20 (one fifth of a dollar), it is preferred in those situations.
不仅仅是MySQL, float和decimal类型之间的区别是它们表示分数值的方式。在二进制浮点类型代表分数,这只能代表值{ m * 2 ^ n | m,n个整数}。如1/5这样的值不能精确地表示(没有舍入误差)。十进制数同样是有限的，但表示数字，如{m*10 n | m, n整数}。小数仍然不能表示像1/3这样的数字，但是在许多常见的领域中，比如金融，通常情况下，期望是某些小数部分可以一直表示而不失去保真度。由于十进制数可以表示$0.20(一美元的五分之一)，所以在这些情况下它是首选。
#5
10
decimal is for fixed quantities like money where you want a specific number of decimal places. Floats are for storing ... floating point precision numbers.
小数是固定数量的，比如钱，你想要一个特定的小数位数。浮动是用来存储的…精度浮点数字。
#6
7
mysql> CREATE TABLE num(id int ,fl float,dc dec(5,2));
Query OK, 0 rows affected (0.00 sec)
mysql> INSERT INTO num VALUES(1,13.75,13.75);
Query OK, 1 row affected (0.00 sec)
mysql> INSERT INTO num VALUES(2,13.15,13.15);
Query OK, 1 row affected (0.00 sec)
mysql> SELECT * FROM num WHERE fl = 13.15;
Empty set (0.00 sec)
mysql> SELECT * FROM num WHERE dc = 13.15;
+------+-------+-------+
| id | fl | dc |
+------+-------+-------+
| 2 | 13.15 | 13.15 |
+------+-------+-------+
1 row in set (0.00 sec)
mysql> SELECT SUM(fl) ,SUM(dc) FROM num;
+--------------------+---------+
| SUM(fl) | SUM(dc) |
+--------------------+---------+
| 26.899999618530273 | 26.90 |
+--------------------+---------+
1 row in set (0.00 sec)
mysql> SELECT * FROM num WHERE ABS(fl - 13.15)<0.01;
+------+-------+-------+
| id | fl | dc |
+------+-------+-------+
| 2 | 13.15 | 13.15 |
+------+-------+-------+
1 row in set (0.00 sec)
#7
5
Float:
浮动:
A small (single-precision) floating-point number. Allowable values are -3.402823466E+38 to -1.175494351E-38,0, and 1.175494351E-38 to 3.402823466E+38. These are the theoretical limits, based on the IEEE standard. The actual range might be slightly smaller depending on your hardware or operating system.
一个小(单精度)浮点数。允许值为-3.402823466E+38至- 1.175494351e -38,0，和1.175494351E-38至3.402823466E+38。这是基于IEEE标准的理论限制。实际的范围可能会稍微小一些，这取决于您的硬件或操作系统。
DECIMAL:
小数:
A packed “exact” fixed-point number. M is the total number of digits (the precision) and D is the number of digits after the decimal point (the scale). The decimal point and (for negative numbers) the “-” sign are not counted inM. If D is 0, values have no decimal point or fractional part. The maximum number of digits (M) for DECIMAL is 65. The maximum number of supported decimals (D) is 30. If D is omitted, the default is 0. If M is omitted, the default is 10.
一个打包的“精确”的定点数。M是数字(精度)的总数，D是小数点后位数(刻度)。小数点和(对于负数)“-”符号不被计算在内。如果D是0，则值没有小数点或小数部分。小数的最大位数(M)是65。支持的小数的最大数目(D)是30。如果省略D，默认值为0。如果省略M，默认值是10。
#8
4
I found this useful:
我发现这有用:
Generally, Float values are good for scientific Calculations, but should not be used for Financial/Monetary Values. For Business Oriented Math, always use Decimal.
一般来说，浮动值有利于科学计算，但不应用于金融/货币价值。对于面向业务的数学，总是使用十进制。
Source: http://code.rohitink.com/2013/06/12/mysql-integer-float-decimal-data-types-differences/
来源:http://code.rohitink.com/2013/06/12/mysql-integer-float-decimal-data-types-differences/
#9
3
If you are after performance and not precision, you should note that calculations with floats are much faster than decimals
如果您是在性能而不是精度之后，您应该注意到，浮点数的计算要比小数快得多。
#10
2
Floating-Point Types (Approximate Value) - FLOAT, DOUBLE
浮点类型(近似值)- FLOAT, DOUBLE。
The FLOAT and DOUBLE types represent approximate numeric data values. MySQL uses four bytes for single-precision values and eight bytes for double-precision values.
FLOAT和DOUBLE类型表示近似的数值数据值。MySQL使用四个字节为单精度值，8字节为双精度值。
For FLOAT, the SQL standard permits an optional specification of the precision (but not the range of the exponent) in bits following the keyword FLOAT in parentheses. MySQL also supports this optional precision specification, but the precision value is used only to determine storage size. A precision from 0 to 23 results in a 4-byte single-precision FLOAT column. A precision from 24 to 53 results in an 8-byte double-precision DOUBLE column.
对于浮点数，SQL标准允许一个可选的精度规范(但不是指数的范围)，在关键字后面加括号。MySQL还支持这个可选的精度规范，但是精度值只用于确定存储大小。在一个4字节的单精度浮点列中，从0到23的精度。从24到53的精度结果是一个8字节的双精度双列。
MySQL permits a nonstandard syntax: FLOAT(M,D) or REAL(M,D) or DOUBLE PRECISION(M,D). Here, “(M,D)” means than values can be stored with up to M digits in total, of which D digits may be after the decimal point. For example, a column defined as FLOAT(7,4) will look like -999.9999 when displayed. MySQL performs rounding when storing values, so if you insert 999.00009 into a FLOAT(7,4) column, the approximate result is 999.0001.
MySQL允许非标准语法:FLOAT(M,D)或REAL(M,D)或DOUBLE PRECISION(M,D)。在这里，“(M,D)”的意思是，值可以被存储到总数的M位数，其中D位数可能在小数点后。例如，一个定义为FLOAT(7,4)的列在显示时看起来像-999.9999。在存储值时，MySQL执行四舍五入，因此如果将999.00009插入到FLOAT(7,4)列中，其近似结果为999.0001。
Because floating-point values are approximate and not stored as exact values, attempts to treat them as exact in comparisons may lead to problems. They are also subject to platform or implementation dependencies.
由于浮点值是近似的，而不是作为精确值存储的，因此将它们视为精确的比较可能会导致问题。它们还受制于平台或实现依赖关系。
For maximum portability, code requiring storage of approximate numeric data values should use FLOAT or DOUBLE PRECISION with no specification of precision or number of digits.
为了获得最大的可移植性，需要存储近似数值数据值的代码应该使用浮点数或双精度，而不需要指定精度或位数。
https://dev.mysql.com/doc/refman/5.5/en/floating-point-types.html
https://dev.mysql.com/doc/refman/5.5/en/floating-point-types.html
Problems with Floating-Point Values
浮点值的问题
Floating-point numbers sometimes cause confusion because they are approximate and not stored as exact values. A floating-point value as written in an SQL statement may not be the same as the value represented internally. Attempts to treat floating-point values as exact in comparisons may lead to problems. They are also subject to platform or implementation dependencies. The FLOAT and DOUBLE data types are subject to these issues. For DECIMAL columns, MySQL performs operations with a precision of 65 decimal digits, which should solve most common inaccuracy problems.
浮点数有时会引起混淆，因为它们是近似的，而不是作为精确值存储的。在SQL语句中写入的浮点值可能与内部表示的值不一样。试图将浮点值当作精确的比较来处理可能会导致问题。它们还受制于平台或实现依赖关系。浮动和双数据类型受这些问题的影响。对于十进制的列，MySQL执行运算的精度为65位小数，这应该可以解决最常见的不精确问题。
The following example uses DOUBLE to demonstrate how calculations that are done using floating-point operations are subject to floating-point error.
下面的示例使用了DOUBLE来演示如何使用浮点操作来完成计算，这将受到浮点错误的影响。
mysql> CREATE TABLE t1 (i INT, d1 DOUBLE, d2 DOUBLE);
mysql> INSERT INTO t1 VALUES (1, 101.40, 21.40), (1, -80.00, 0.00),
-> (2, 0.00, 0.00), (2, -13.20, 0.00), (2, 59.60, 46.40),
-> (2, 30.40, 30.40), (3, 37.00, 7.40), (3, -29.60, 0.00),
-> (4, 60.00, 15.40), (4, -10.60, 0.00), (4, -34.00, 0.00),
-> (5, 33.00, 0.00), (5, -25.80, 0.00), (5, 0.00, 7.20),
-> (6, 0.00, 0.00), (6, -51.40, 0.00);
mysql> SELECT i, SUM(d1) AS a, SUM(d2) AS b
-> FROM t1 GROUP BY i HAVING a <> b;
+------+-------+------+
| i | a | b |
+------+-------+------+
| 1 | 21.4 | 21.4 |
| 2 | 76.8 | 76.8 |
| 3 | 7.4 | 7.4 |
| 4 | 15.4 | 15.4 |
| 5 | 7.2 | 7.2 |
| 6 | -51.4 | 0 |
+------+-------+------+
The result is correct. Although the first five records look like they should not satisfy the comparison (the values of a and b do not appear to be different), they may do so because the difference between the numbers shows up around the tenth decimal or so, depending on factors such as computer architecture or the compiler version or optimization level. For example, different CPUs may evaluate floating-point numbers differently.
结果是正确的。尽管前五的记录看起来不应该满足的比较(a和b的值不似乎是不同的),他们会这样做,因为这些数字之间的区别出现小数点第十左右,根据计算机体系结构等因素或编译器版本或优化级别。例如，不同的cpu可以不同地评估浮点数。
If columns d1 and d2 had been defined as DECIMAL rather than DOUBLE, the result of the SELECT query would have contained only one row—the last one shown above.
如果列d1和d2被定义为DECIMAL而不是DOUBLE，那么SELECT查询的结果将只包含一个行——上面显示的最后一个行。
The correct way to do floating-point number comparison is to first decide on an acceptable tolerance for differences between the numbers and then do the comparison against the tolerance value. For example, if we agree that floating-point numbers should be regarded the same if they are same within a precision of one in ten thousand (0.0001), the comparison should be written to find differences larger than the tolerance value:
进行浮点数比较的正确方法是首先确定一个可接受的对数字之间的差异的容忍度，然后对公差值进行比较。例如，如果我们同意浮点数在1万(0.0001)的精度相同的情况下应该被视为相同的，那么应该用比较来发现大于公差值的差异:
mysql> SELECT i, SUM(d1) AS a, SUM(d2) AS b FROM t1
-> GROUP BY i HAVING ABS(a - b) > 0.0001;
+------+-------+------+
| i | a | b |
+------+-------+------+
| 6 | -51.4 | 0 |
+------+-------+------+
1 row in set (0.00 sec)
Conversely, to get rows where the numbers are the same, the test should find differences within the tolerance value:
相反地，要得到数字相同的行，测试应该在公差值内发现差异:
mysql> SELECT i, SUM(d1) AS a, SUM(d2) AS b FROM t1
-> GROUP BY i HAVING ABS(a - b) <= 0.0001;
+------+------+------+
| i | a | b |
+------+------+------+
| 1 | 21.4 | 21.4 |
| 2 | 76.8 | 76.8 |
| 3 | 7.4 | 7.4 |
| 4 | 15.4 | 15.4 |
| 5 | 7.2 | 7.2 |
+------+------+------+
5 rows in set (0.03 sec)
Floating-point values are subject to platform or implementation dependencies. Suppose that you execute the following statements:
浮点值取决于平台或实现依赖项。假设您执行以下语句:
CREATE TABLE t1(c1 FLOAT(53,0), c2 FLOAT(53,0));
INSERT INTO t1 VALUES('1e+52','-1e+52');
SELECT * FROM t1;
On some platforms, the SELECT statement returns inf and -inf. On others, it returns 0 and -0.
在某些平台上，SELECT语句返回inf和-inf。在其他情况下，它返回0和-0。
An implication of the preceding issues is that if you attempt to create a replication slave by dumping table contents with mysqldump on the master and reloading the dump file into the slave, tables containing floating-point columns might differ between the two hosts.
前面的问题的含义是，如果您试图通过将表内容转储到主服务器上并将转储文件重新加载到该服务器，来创建一个复制奴隶，那么包含浮点列的表可能会在两个主机之间有所不同。
https://dev.mysql.com/doc/refman/5.5/en/problems-with-float.html
https://dev.mysql.com/doc/refman/5.5/en/problems-with-float.html
#11
1
Hard & Fast Rule
精确和标准
If all you need to do is add, subtract or multiply the numbers you are storing, DECIMAL is best.
如果你需要做的只是加、减或乘你所储存的数字，十进制是最好的。
If you need to divide or do any other form of arithmetic or algebra on the data you're almost certainly going to be happier with float. Floating point libraries, and on Intel processors, the floating point processor itself, have TONs of operations to correct, fix-up, detect and handle the blizzard of exceptions that occur when doing typical math functions - especially transcendental functions.
如果你需要在数据上划分或做其他形式的算术或代数，你几乎肯定会对浮点数更满意。浮点程序库，以及在Intel处理器上的浮点处理器本身，有大量的操作来纠正、修复、检测和处理在执行典型的数学函数时发生的大量异常——尤其是超越函数。
As for accuracy, I once wrote a budget system that computed the % contribution of each of 3,000+ accounts, for 3,600 budget units, by month to that unit's consolidation node, then based on that matrix of percentages (3,000 + x 12 x 3,600) I multiplied the amounts budgeted by the highest organizational nodes down to the next 3 levels of the organizational nodes, and then computed all (3,000 + 12) values for all 3,200 detail units from that. Millions and millions and millions of double precision floating point calculations, any one of which would throw off the roll-up of all of those projections in a bottoms-up consolidation back to the highest level in the organization.
至于准确性,我曾写过一个预算系统,计算每个3000 + %的贡献账户,3600年的预算单位,由单位的月合并节点,然后基于矩阵的百分比(3000 + 12 x 3600)我预算的金额乘以最高的组织节点下未来3级别的组织节点,然后计算所有(3000 + 12)值3200详细单位。数以百万计的双精度浮点计算，其中任何一项都将把所有这些预测的结果都推到组织的最高层。
The total floating point error after all of those calculations was ZERO. That was in 1986, and floating point libraries today are much, much better than they were back then. Intel does all of it's intermediate calculations of doubles in 80 bit precision, which all but eliminates rounding error. When someone tells you "it's floating point error" it's almost certainty NOT true.
所有这些计算后的总浮点误差为零。那是在1986年，现在的浮点库比当时的要好多了。英特尔做了所有的中间计算，在80位精度的两倍，这几乎消除了舍入误差。当有人告诉你“这是浮点错误”时，几乎肯定不是真的。
#12
0
float (and double) represents binary fractions
float(和double)表示二进制分数。
decimal represents decimal fractions
十进制表示十进制分数
#13
-1
declare @float as float(10)
declare @Decimal as decimal(10)
declare @Inetger as int
set @float =10.7
set @Decimal =10.7
set @Inetger=@Decimal
print @Inetger
in float when set value to integer print 10 but in decimal 11
在浮点中，当将值设置为整数打印10时，但在十进制中。
#1
169
This is what I found when I had this doubt.
这是我在怀疑的时候发现的。
mysql> create table numbers (a decimal(10,2), b float);
mysql> insert into numbers values (100, 100);
mysql> select @a := (a/3), @b := (b/3), @a * 3, @b * 3 from numbers \G
*************************** 1. row ***************************
@a := (a/3): 33.333333333
@b := (b/3): 33.333333333333
@a + @a + @a: 99.999999999000000000000000000000
@b + @b + @b: 100
The decimal did exactly what's supposed to do on this cases, it truncated the rest, thus losing the 1/3 part.
小数点在这种情况下做了正确的事情，它截断了剩下的部分，从而失去了1/3部分。
So for sums the decimal is better, but for divisions the float is better, up to some point, of course. I mean, using DECIMAL will not give you a "fail proof arithmetic" in any means.
因此，对于加法，小数是更好的，但对于划分，浮动是更好的，当然，在某种程度上。我的意思是，使用十进制不会给你一个“fail proof算术”。
Hope this helps.
希望这个有帮助。
#2
70
A "float" in most environments is a binary floating-point type. It can accurately store base-2 values (to a certain point), but cannot accurately store many base-10 (decimal) values. Floats are most appropriate for scientific calculations. They're not appropriate for most business-oriented math, and inappropriate use of floats will bite you. Many decimal values can't be exactly represented in base-2. 0.1 can't, for instance, and so you see strange results like 1.0 - 0.1 = 0.8999999.
在大多数环境中，“浮动”是二进制浮点类型。它可以准确地存储base-2值(到某个点)，但不能准确存储许多base-10 (decimal)值。浮动最适合科学计算。它们不适合大多数以业务为导向的数学，不恰当地使用浮动将会影响你。在base-2中不能精确地表示许多十进制值。例如，0.1不能，所以你会看到一些奇怪的结果，比如1.0 - 0.1 = 0.8999999。
Decimals store base-10 numbers. Decimal is an good type for most business math (but any built-in "money" type is more appropriate for financial calculations), where the range of values exceeds that provided by integer types, and fractional values are needed. Decimals, as the name implies, are designed for base-10 numbers - they can accurately store decimal values (again, to a certain point).
小数商店八进制数数数。对于大多数业务数学来说，十进制是一种很好的类型(但是任何内置的“货币”类型更适合于财务计算)，在这里，值的范围超过了整数类型提供的值，并且需要分数值。小数，顾名思义，是为基数10的数字设计的——它们可以精确地存储十进制值(再一次，到某个点)。
#3
21
MySQL recently changed they way they store the DECIMAL type. In the past they stored the characters (or nybbles) for each digit comprising an ASCII (or nybble) representation of a number - vs - a two's complement integer, or some derivative thereof.
MySQL最近改变了他们存储十进制的方式。在过去，他们将字符(或nybbles)存储为一个数字- vs的一个ASCII(或nybble)表示形式——一个二进制的补体整数，或其中的一些导数。
The current storage format for DECIMAL is a series of 1,2,3,or 4-byte integers whose bits are concatenated to create a two's complement number with an implied decimal point, defined by you, and stored in the DB schema when you declare the column and specify it's DECIMAL size and decimal point position.
目前的十进制存储格式是一系列的1,2,3,或4字节整数的位连接创建一个二进制补码数隐含小数点,由你定义的,并存储在DB模式当你声明列和指定的小数大小和小数点的位置。
By way of example, if you take a 32-bit int you can store any number from 0 - 4,294,967,295. That will only reliably cover 999,999,999, so if you threw out 2 bits and used (1<<30 -1) you'd give up nothing. Covering all 9-digit numbers with only 4 bytes is more efficient than covering 4 digits in 32 bits using 4 ASCII characters, or 8 nybble digits. (a nybble is 4-bits, allowing values 0-15, more than is needed for 0-9, but you can't eliminate that waste by going to 3 bits, because that only covers values 0-7)
举例来说，如果您使用一个32位的整数，您可以从0 - 4,294,967,295中存储任何数字。这只会可靠地覆盖999,999,999，所以如果你抛出2位，并且使用(1<<30 -1)，你将放弃任何东西。覆盖所有9位数字，只有4个字节，比用4个ASCII字符或8个nybble数字覆盖32位的4位数字更有效。(nybble是4位，允许0-15的值，比0-9需要更多，但是你不能把这些浪费掉到3位，因为这只包含0-7的值)
The example used on the MySQL online docs uses DECIMAL(18,9) as an example. This is 9 digits ahead of and 9 digits behind the implied decimal point, which as explained above requires the following storage.
在MySQL在线文档中使用的示例使用十进制(18,9)作为示例。这是9位数字，在隐含小数点后面9位，如上所述，需要以下存储。
As 18 8-bit chars: 144 bits
18 -位字符:144位。
As 18 4-bit nybbles: 72 bits
有18个4位的小石子:72位。
As 2 32-bit integers: 64 bits
作为两个32位整数:64位。
Currently DECIMAL supports a max of 65 digits, as DECIMAL(M,D) where the largest value for M allowed is 65, and the largest value of D allowed is 30.
目前，十进制支持最大的65位数字，如十进制(M,D)，其中M允许的最大值是65，允许的最大值是30。
So as not to require chunks of 9 digits at a time, integers smaller than 32-bits are used to add digits using 1,2 and 3 byte integers. For some reason that defies logic, signed, instead of unsigned ints were used, and in so doing, 1 bit gets thrown out, resulting in the following storage capabilities. For 1,2 and 4 byte ints the lost bit doesn't matter, but for the 3-byte int it's a disaster because an entire digit is lost due to the loss of that single bit.
因此，为了不需要一次使用9个数字块，可以使用小于32位的整数来使用1、2和3字节整数添加数字。由于某些原因，使用的是不符合逻辑的，而不是使用未签名的ints，这样做时，1位被抛出，导致了以下存储能力。对于1、2和4字节的字节来说，丢失的比特并不重要，但是对于3字节的整数来说，这是一场灾难，因为丢失了这一比特位就丢失了整个数字。
With an 7-bit int: 0 - 99
以7位整数:0 - 99。
With a 15-bit int: 0 - 9,999
有15位整数:0 - 99999。
With a 23-bit int: 0 - 999,999 (0 - 9,999,999 with a 24-bit int)
有一个23位整数:0 - 999,999(0 - 9,999,999和24位整数)
1,2,3 and 4-byte integers are concatenated together to form a "bit pool" DECIMAL uses to represent the number precisely as a two's complement integer. The decimal point is NOT stored, it is implied.
1、2、3和4字节的整数被连接在一起，形成一个“位池”小数，用来表示精确的数字作为一个2的补体整数。它是隐式的，不存储小数点。
This means that no ASCII to int conversions are required of the DB engine to convert the "number" into something the CPU recognizes as a number. No rounding, no conversion errors, it's a real number the CPU can manipulate.
这意味着，对于DB引擎来说，不需要使用任何ASCII来转换“数字”，从而将“数字”转换成CPU能够识别的数字。没有四舍五入，没有转换错误，这是CPU可以操作的实数。
Calculations on this arbitrarily large integer must be done in software, as there is no hardware support for this kind of number, but these libraries are very old and highly optimized, having been written 50 years ago to support IBM 370 Fortran arbitrary precision floating point data. They're still a lot slower than fixed-sized integer algebra done with CPU integer hardware, or floating point calculations done on the FPU.
对于这个任意大的整数的计算必须在软件中进行，因为对于这种数字没有硬件支持，但是这些库是非常古老和高度优化的，已经在50年前编写，以支持IBM 370 Fortran任意精度浮点数据。它们仍然比用CPU整数硬件完成的固定大小的整数代数慢得多，或者在FPU上做浮点运算。
In terms of storage efficiency, because the exponent of a float is attached to each and every float, specifying implicitly where the decimal point is, it is massively redundant, and therefore inefficient for DB work. In a DB you already know where the decimal point is to go up front, and every row in the table that has a value for a DECIMAL column need only look at the 1 & only specification of where that decimal point is to be placed, stored in the schema as the arguments to a DECIMAL(M,D) as the implication of the M and the D values.
在存储效率方面，因为浮点数的指数是附加在每个浮点数上的，它隐含地指定小数点的位置，因此它是大量冗余的，因此对DB的工作效率很低。在DB你已经知道小数点在哪里去,和表中的每一行一个十进制值列只需要看1 &只有规范的小数点是被放置的地方,作为一个十进制的参数存储模式中(M,D)的含义M和D值。
The many remarks found here about which format is to be used for various kinds of applications are correct, so I won't belabor the point. I took the time to write this here because whoever is maintaining the linked MySQL online documentation doesn't understand any of the above and after rounds of increasingly frustrating attempts to explain it to them I gave up. A good indication of how poorly they understood what they were writing is the very muddled and almost indecipherable presentation of the subject matter.
这里发现的关于各种应用程序的格式是正确的，所以我不赘述。我花了时间在这里写这篇文章，因为不管谁在维护这个链接的MySQL在线文档，我都不理解上面的任何内容，并且在不断地尝试向他们解释我放弃的时候，我也不明白。一个很好的迹象表明，他们对所写内容的理解是多么的糟糕，这是一个非常混乱和几乎无法解释的主题。
As a final thought, if you have need of high-precision floating point computation, there've been tremendous advances in floating point code in the last 20 years, and hardware support for 96-bit and Quadruple Precision float are right around the corner, but there are good arbitrary precision libraries out there if manipulation of the stored value is important.
最后认为,如果你有需要高精度的浮点计算,浮点代码中有巨大的进步在过去的20年里,和硬件支持96位和四精密浮动右拐角处,但是有好的高精度库如果操纵存储的值是很重要的。
#4
13
Not just specific to MySQL, the difference between float and decimal types is the way that they represent fractional values. Floating point types represent fractions in binary, which can only represent values as {m*2^n | m, n Integers} . values such as 1/5 cannot be precisely represented (without round off error). Decimal numbers are similarly limited, but represent numbers like {m*10^n | m, n Integers}. Decimals still cannot represent numbers like 1/3, but it is often the case in many common fields, like finance, that the expectation is that certain decimal fractions can always be expressed without loss of fidelity. Since a decimal number can represent a value like $0.20 (one fifth of a dollar), it is preferred in those situations.
不仅仅是MySQL, float和decimal类型之间的区别是它们表示分数值的方式。在二进制浮点类型代表分数,这只能代表值{ m * 2 ^ n | m,n个整数}。如1/5这样的值不能精确地表示(没有舍入误差)。十进制数同样是有限的，但表示数字，如{m*10 n | m, n整数}。小数仍然不能表示像1/3这样的数字，但是在许多常见的领域中，比如金融，通常情况下，期望是某些小数部分可以一直表示而不失去保真度。由于十进制数可以表示$0.20(一美元的五分之一)，所以在这些情况下它是首选。
#5
10
decimal is for fixed quantities like money where you want a specific number of decimal places. Floats are for storing ... floating point precision numbers.
小数是固定数量的，比如钱，你想要一个特定的小数位数。浮动是用来存储的…精度浮点数字。
#6
7
mysql> CREATE TABLE num(id int ,fl float,dc dec(5,2));
Query OK, 0 rows affected (0.00 sec)
mysql> INSERT INTO num VALUES(1,13.75,13.75);
Query OK, 1 row affected (0.00 sec)
mysql> INSERT INTO num VALUES(2,13.15,13.15);
Query OK, 1 row affected (0.00 sec)
mysql> SELECT * FROM num WHERE fl = 13.15;
Empty set (0.00 sec)
mysql> SELECT * FROM num WHERE dc = 13.15;
+------+-------+-------+
| id | fl | dc |
+------+-------+-------+
| 2 | 13.15 | 13.15 |
+------+-------+-------+
1 row in set (0.00 sec)
mysql> SELECT SUM(fl) ,SUM(dc) FROM num;
+--------------------+---------+
| SUM(fl) | SUM(dc) |
+--------------------+---------+
| 26.899999618530273 | 26.90 |
+--------------------+---------+
1 row in set (0.00 sec)
mysql> SELECT * FROM num WHERE ABS(fl - 13.15)<0.01;
+------+-------+-------+
| id | fl | dc |
+------+-------+-------+
| 2 | 13.15 | 13.15 |
+------+-------+-------+
1 row in set (0.00 sec)
#7
5
Float:
浮动:
A small (single-precision) floating-point number. Allowable values are -3.402823466E+38 to -1.175494351E-38,0, and 1.175494351E-38 to 3.402823466E+38. These are the theoretical limits, based on the IEEE standard. The actual range might be slightly smaller depending on your hardware or operating system.
一个小(单精度)浮点数。允许值为-3.402823466E+38至- 1.175494351e -38,0，和1.175494351E-38至3.402823466E+38。这是基于IEEE标准的理论限制。实际的范围可能会稍微小一些，这取决于您的硬件或操作系统。
DECIMAL:
小数:
A packed “exact” fixed-point number. M is the total number of digits (the precision) and D is the number of digits after the decimal point (the scale). The decimal point and (for negative numbers) the “-” sign are not counted inM. If D is 0, values have no decimal point or fractional part. The maximum number of digits (M) for DECIMAL is 65. The maximum number of supported decimals (D) is 30. If D is omitted, the default is 0. If M is omitted, the default is 10.
一个打包的“精确”的定点数。M是数字(精度)的总数，D是小数点后位数(刻度)。小数点和(对于负数)“-”符号不被计算在内。如果D是0，则值没有小数点或小数部分。小数的最大位数(M)是65。支持的小数的最大数目(D)是30。如果省略D，默认值为0。如果省略M，默认值是10。
#8
4
I found this useful:
我发现这有用:
Generally, Float values are good for scientific Calculations, but should not be used for Financial/Monetary Values. For Business Oriented Math, always use Decimal.
一般来说，浮动值有利于科学计算，但不应用于金融/货币价值。对于面向业务的数学，总是使用十进制。
Source: http://code.rohitink.com/2013/06/12/mysql-integer-float-decimal-data-types-differences/
来源:http://code.rohitink.com/2013/06/12/mysql-integer-float-decimal-data-types-differences/
#9
3
If you are after performance and not precision, you should note that calculations with floats are much faster than decimals
如果您是在性能而不是精度之后，您应该注意到，浮点数的计算要比小数快得多。
#10
2
Floating-Point Types (Approximate Value) - FLOAT, DOUBLE
浮点类型(近似值)- FLOAT, DOUBLE。
The FLOAT and DOUBLE types represent approximate numeric data values. MySQL uses four bytes for single-precision values and eight bytes for double-precision values.
FLOAT和DOUBLE类型表示近似的数值数据值。MySQL使用四个字节为单精度值，8字节为双精度值。
For FLOAT, the SQL standard permits an optional specification of the precision (but not the range of the exponent) in bits following the keyword FLOAT in parentheses. MySQL also supports this optional precision specification, but the precision value is used only to determine storage size. A precision from 0 to 23 results in a 4-byte single-precision FLOAT column. A precision from 24 to 53 results in an 8-byte double-precision DOUBLE column.
对于浮点数，SQL标准允许一个可选的精度规范(但不是指数的范围)，在关键字后面加括号。MySQL还支持这个可选的精度规范，但是精度值只用于确定存储大小。在一个4字节的单精度浮点列中，从0到23的精度。从24到53的精度结果是一个8字节的双精度双列。
MySQL permits a nonstandard syntax: FLOAT(M,D) or REAL(M,D) or DOUBLE PRECISION(M,D). Here, “(M,D)” means than values can be stored with up to M digits in total, of which D digits may be after the decimal point. For example, a column defined as FLOAT(7,4) will look like -999.9999 when displayed. MySQL performs rounding when storing values, so if you insert 999.00009 into a FLOAT(7,4) column, the approximate result is 999.0001.
MySQL允许非标准语法:FLOAT(M,D)或REAL(M,D)或DOUBLE PRECISION(M,D)。在这里，“(M,D)”的意思是，值可以被存储到总数的M位数，其中D位数可能在小数点后。例如，一个定义为FLOAT(7,4)的列在显示时看起来像-999.9999。在存储值时，MySQL执行四舍五入，因此如果将999.00009插入到FLOAT(7,4)列中，其近似结果为999.0001。
Because floating-point values are approximate and not stored as exact values, attempts to treat them as exact in comparisons may lead to problems. They are also subject to platform or implementation dependencies.
由于浮点值是近似的，而不是作为精确值存储的，因此将它们视为精确的比较可能会导致问题。它们还受制于平台或实现依赖关系。
For maximum portability, code requiring storage of approximate numeric data values should use FLOAT or DOUBLE PRECISION with no specification of precision or number of digits.
为了获得最大的可移植性，需要存储近似数值数据值的代码应该使用浮点数或双精度，而不需要指定精度或位数。
https://dev.mysql.com/doc/refman/5.5/en/floating-point-types.html
https://dev.mysql.com/doc/refman/5.5/en/floating-point-types.html
Problems with Floating-Point Values
浮点值的问题
Floating-point numbers sometimes cause confusion because they are approximate and not stored as exact values. A floating-point value as written in an SQL statement may not be the same as the value represented internally. Attempts to treat floating-point values as exact in comparisons may lead to problems. They are also subject to platform or implementation dependencies. The FLOAT and DOUBLE data types are subject to these issues. For DECIMAL columns, MySQL performs operations with a precision of 65 decimal digits, which should solve most common inaccuracy problems.
浮点数有时会引起混淆，因为它们是近似的，而不是作为精确值存储的。在SQL语句中写入的浮点值可能与内部表示的值不一样。试图将浮点值当作精确的比较来处理可能会导致问题。它们还受制于平台或实现依赖关系。浮动和双数据类型受这些问题的影响。对于十进制的列，MySQL执行运算的精度为65位小数，这应该可以解决最常见的不精确问题。
The following example uses DOUBLE to demonstrate how calculations that are done using floating-point operations are subject to floating-point error.
下面的示例使用了DOUBLE来演示如何使用浮点操作来完成计算，这将受到浮点错误的影响。
mysql> CREATE TABLE t1 (i INT, d1 DOUBLE, d2 DOUBLE);
mysql> INSERT INTO t1 VALUES (1, 101.40, 21.40), (1, -80.00, 0.00),
-> (2, 0.00, 0.00), (2, -13.20, 0.00), (2, 59.60, 46.40),
-> (2, 30.40, 30.40), (3, 37.00, 7.40), (3, -29.60, 0.00),
-> (4, 60.00, 15.40), (4, -10.60, 0.00), (4, -34.00, 0.00),
-> (5, 33.00, 0.00), (5, -25.80, 0.00), (5, 0.00, 7.20),
-> (6, 0.00, 0.00), (6, -51.40, 0.00);
mysql> SELECT i, SUM(d1) AS a, SUM(d2) AS b
-> FROM t1 GROUP BY i HAVING a <> b;
+------+-------+------+
| i | a | b |
+------+-------+------+
| 1 | 21.4 | 21.4 |
| 2 | 76.8 | 76.8 |
| 3 | 7.4 | 7.4 |
| 4 | 15.4 | 15.4 |
| 5 | 7.2 | 7.2 |
| 6 | -51.4 | 0 |
+------+-------+------+
The result is correct. Although the first five records look like they should not satisfy the comparison (the values of a and b do not appear to be different), they may do so because the difference between the numbers shows up around the tenth decimal or so, depending on factors such as computer architecture or the compiler version or optimization level. For example, different CPUs may evaluate floating-point numbers differently.
结果是正确的。尽管前五的记录看起来不应该满足的比较(a和b的值不似乎是不同的),他们会这样做,因为这些数字之间的区别出现小数点第十左右,根据计算机体系结构等因素或编译器版本或优化级别。例如，不同的cpu可以不同地评估浮点数。
If columns d1 and d2 had been defined as DECIMAL rather than DOUBLE, the result of the SELECT query would have contained only one row—the last one shown above.
如果列d1和d2被定义为DECIMAL而不是DOUBLE，那么SELECT查询的结果将只包含一个行——上面显示的最后一个行。
The correct way to do floating-point number comparison is to first decide on an acceptable tolerance for differences between the numbers and then do the comparison against the tolerance value. For example, if we agree that floating-point numbers should be regarded the same if they are same within a precision of one in ten thousand (0.0001), the comparison should be written to find differences larger than the tolerance value:
进行浮点数比较的正确方法是首先确定一个可接受的对数字之间的差异的容忍度，然后对公差值进行比较。例如，如果我们同意浮点数在1万(0.0001)的精度相同的情况下应该被视为相同的，那么应该用比较来发现大于公差值的差异:
mysql> SELECT i, SUM(d1) AS a, SUM(d2) AS b FROM t1
-> GROUP BY i HAVING ABS(a - b) > 0.0001;
+------+-------+------+
| i | a | b |
+------+-------+------+
| 6 | -51.4 | 0 |
+------+-------+------+
1 row in set (0.00 sec)
Conversely, to get rows where the numbers are the same, the test should find differences within the tolerance value:
相反地，要得到数字相同的行，测试应该在公差值内发现差异:
mysql> SELECT i, SUM(d1) AS a, SUM(d2) AS b FROM t1
-> GROUP BY i HAVING ABS(a - b) <= 0.0001;
+------+------+------+
| i | a | b |
+------+------+------+
| 1 | 21.4 | 21.4 |
| 2 | 76.8 | 76.8 |
| 3 | 7.4 | 7.4 |
| 4 | 15.4 | 15.4 |
| 5 | 7.2 | 7.2 |
+------+------+------+
5 rows in set (0.03 sec)
Floating-point values are subject to platform or implementation dependencies. Suppose that you execute the following statements:
浮点值取决于平台或实现依赖项。假设您执行以下语句:
CREATE TABLE t1(c1 FLOAT(53,0), c2 FLOAT(53,0));
INSERT INTO t1 VALUES('1e+52','-1e+52');
SELECT * FROM t1;
On some platforms, the SELECT statement returns inf and -inf. On others, it returns 0 and -0.
在某些平台上，SELECT语句返回inf和-inf。在其他情况下，它返回0和-0。
An implication of the preceding issues is that if you attempt to create a replication slave by dumping table contents with mysqldump on the master and reloading the dump file into the slave, tables containing floating-point columns might differ between the two hosts.
前面的问题的含义是，如果您试图通过将表内容转储到主服务器上并将转储文件重新加载到该服务器，来创建一个复制奴隶，那么包含浮点列的表可能会在两个主机之间有所不同。
https://dev.mysql.com/doc/refman/5.5/en/problems-with-float.html
https://dev.mysql.com/doc/refman/5.5/en/problems-with-float.html
#11
1
Hard & Fast Rule
精确和标准
If all you need to do is add, subtract or multiply the numbers you are storing, DECIMAL is best.
如果你需要做的只是加、减或乘你所储存的数字，十进制是最好的。
If you need to divide or do any other form of arithmetic or algebra on the data you're almost certainly going to be happier with float. Floating point libraries, and on Intel processors, the floating point processor itself, have TONs of operations to correct, fix-up, detect and handle the blizzard of exceptions that occur when doing typical math functions - especially transcendental functions.
如果你需要在数据上划分或做其他形式的算术或代数，你几乎肯定会对浮点数更满意。浮点程序库，以及在Intel处理器上的浮点处理器本身，有大量的操作来纠正、修复、检测和处理在执行典型的数学函数时发生的大量异常——尤其是超越函数。
As for accuracy, I once wrote a budget system that computed the % contribution of each of 3,000+ accounts, for 3,600 budget units, by month to that unit's consolidation node, then based on that matrix of percentages (3,000 + x 12 x 3,600) I multiplied the amounts budgeted by the highest organizational nodes down to the next 3 levels of the organizational nodes, and then computed all (3,000 + 12) values for all 3,200 detail units from that. Millions and millions and millions of double precision floating point calculations, any one of which would throw off the roll-up of all of those projections in a bottoms-up consolidation back to the highest level in the organization.
至于准确性,我曾写过一个预算系统,计算每个3000 + %的贡献账户,3600年的预算单位,由单位的月合并节点,然后基于矩阵的百分比(3000 + 12 x 3600)我预算的金额乘以最高的组织节点下未来3级别的组织节点,然后计算所有(3000 + 12)值3200详细单位。数以百万计的双精度浮点计算，其中任何一项都将把所有这些预测的结果都推到组织的最高层。
The total floating point error after all of those calculations was ZERO. That was in 1986, and floating point libraries today are much, much better than they were back then. Intel does all of it's intermediate calculations of doubles in 80 bit precision, which all but eliminates rounding error. When someone tells you "it's floating point error" it's almost certainty NOT true.
所有这些计算后的总浮点误差为零。那是在1986年，现在的浮点库比当时的要好多了。英特尔做了所有的中间计算，在80位精度的两倍，这几乎消除了舍入误差。当有人告诉你“这是浮点错误”时，几乎肯定不是真的。
#12
0
float (and double) represents binary fractions
float(和double)表示二进制分数。
decimal represents decimal fractions
十进制表示十进制分数
#13
-1
declare @float as float(10)
declare @Decimal as decimal(10)
declare @Inetger as int
set @float =10.7
set @Decimal =10.7
set @Inetger=@Decimal
print @Inetger
in float when set value to integer print 10 but in decimal 11
在浮点中，当将值设置为整数打印10时，但在十进制中。