MySQL中的DOUBLE vs DECIMAL

Question

好的，所以我知道有很多文章说我不应该使用 DOUBLE 在 MySQL 数据库上存储资金，否则我最终会遇到棘手的精度错误。关键是我不是在设计一个新的数据库，而是要求我找到优化现有系统的方法。较新的版本包含 783 个 DOUBLE 类型的列，其中大部分用于存储货币或用于计算货币金额的公式。

所以我对这个主题的第一个意见是，我强烈建议在下一个版本中将 DOUBLE 转换为 DECIMAL，因为 MySQL 文档和每个人都这么说。但后来我找不到任何好的论据来证明这一建议的合理性，原因有以下三个：

• 我们不对数据库执行任何计算。所有操作都在 Java 中使用 BigDecimal 完成，而 MySQL 仅用作结果的普通存储。
• DOUBLE 提供的 15 位精度已经足够了，因为我们主要存储 2 位小数的金额，偶尔也会存储带有 8 位小数的公式参数。
• 我们有 6 年的生产记录，没有由于 MySQL 端的精度损失而导致的已知错误问题。

即使对 18 百万行的表执行操作，例如 SUM 和复数乘法，我也无法执行精度不足的错误。我们实际上并没有在生产中做这种事情。我可以通过执行类似

的操作来显示丢失的精度

SELECT columnName * 1.000000000000000 FROM tableName;

但我想不出办法将它变成小数点后第二位的错误。我在互联网上发现的大多数实际问题都是 2005 年和更早的论坛条目，我无法在 5.0.51 MySQL 服务器上重现它们。

因此，只要我们不执行任何我们不打算执行的 SQL 算术运算，我们是否应该预期仅在 DOUBLE 列中存储和检索金额会出现任何问题？

Answer 1

其实完全不一样。 DOUBLE 会导致舍入问题。如果你做类似0.1 + 0.2 的事情，它会给你类似0.30000000000000004 的事情。我个人不会相信使用浮点数学的财务数据。影响可能很小，但谁知道呢。我宁愿拥有我所知道的可靠数据，而不是近似数据，尤其是在处理货币价值时。

Answer 2

来自 MySQL 文档 http://dev.mysql.com/doc/refman/5.1/en/problems-with-float.html 的示例（我将其缩小，本节的文档与 5.5 相同）

mysql> create table t1 (i int, d1 double, d2 double);

mysql> insert into t1 values (2, 0.00  , 0.00),
                             (2, -13.20, 0.00),
                             (2, 59.60 , 46.40),
                             (2, 30.40 , 30.40);

mysql> select
         i,
         sum(d1) as a,
         sum(d2) as b
       from
         t1
       group by
         i
       having a <> b; -- a != b

+------+-------------------+------+
| i    | a                 | b    |
+------+-------------------+------+
|    2 | 76.80000000000001 | 76.8 |
+------+-------------------+------+
1 row in set (0.00 sec)

基本上，如果你将 a 相加，你会得到 0-13.2+59.6+30.4 = 76.8。如果我们将 b 相加，我们得到 0+0+46.4+30.4=76.8。 a 和 b 的总和是相同的，但 MySQL 文档说：

SQL 语句中写入的浮点值可能与内部表示的值不同。

如果我们用小数重复同样的事情：

mysql> create table t2 (i int, d1 decimal(60,30), d2 decimal(60,30));
Query OK, 0 rows  affected (0.09 sec)

mysql> insert into t2 values (2, 0.00  , 0.00),
                             (2, -13.20, 0.00),
                             (2, 59.60 , 46.40),
                             (2, 30.40 , 30.40);
Query OK, 4 rows affected (0.07 sec)
Records: 4  Duplicates: 0  Warnings: 0

mysql> select
         i,
         sum(d1) as a,
         sum(d2) as b
       from
         t2
       group by
         i
       having a <> b;

Empty set (0.00 sec)

预期的结果是空集。

因此，只要您不执行任何 SQL 算术运算，您就可以使用 DOUBLE，但我仍然更喜欢 DECIMAL。

关于 DECIMAL 的另一点需要注意的是，如果小数部分太大，则四舍五入。示例：

mysql> create table t3 (d decimal(5,2));
Query OK, 0 rows affected (0.07 sec)

mysql> insert into t3 (d) values(34.432);
Query OK, 1 row affected, 1 warning (0.10 sec)

mysql> show warnings;
+-------+------+----------------------------------------+
| Level | Code | Message                                |
+-------+------+----------------------------------------+
| Note  | 1265 | Data truncated for column 'd' at row 1 |
+-------+------+----------------------------------------+
1 row in set (0.00 sec)

mysql> select * from t3;
+-------+
| d     |
+-------+
| 34.43 |
+-------+
1 row in set (0.00 sec)

Answer 3

我们刚刚遇到了同样的问题，但反过来。也就是说，我们将美元金额存储为 DECIMAL，但现在我们发现，例如，MySQL 计算的值是 4.389999999993，但是当将其存储到 DECIMAL 字段时，它将它存储为 4.38 而不是我们想要的 4.39它到。因此，虽然 DOUBLE 可能会导致舍入问题，但 DECIMAL 似乎也会导致一些截断问题。

Answer 4

“仅在 DOUBLE 列中存储和检索金额有什么问题吗？”

听起来在您的方案中不会产生舍入错误，如果有，它们将被转换为 BigDecimal 截断。

所以我会说不。

但是，不能保证将来的某些更改不会带来问题。

Answer 5

来自您的 cmets，

税额四舍五入到小数点后四位，总价四舍五入 到小数点后第二位。

使用 cmets 中的示例，我可能会预见到您有 400 次销售额为 1.47 美元的情况。税前销售额为 588.00 美元，税后销售额总计为 636.51 美元（占税费 48.51 美元）。但是，0.121275 美元 * 400 美元的销售税将为 48.52 美元。

这是一种强迫一分钱差价的方法，尽管是人为的。

我会注意到，IRS 有一些工资税表，他们不关心错误是否低于一定金额（如果没记错的话，0.50 美元）。

您的大问题是：有人在乎某些报告是否偏离一分钱吗？如果您的规格说：是的，准确到一分钱，那么您应该努力转换为十进制。

我曾在一家银行工作，其中一分钱的错误被报告为软件缺陷。我试图（徒劳地）引用软件规范，它不需要这个应用程序的精确度。 （它执行了许多链式乘法。）我还指出了用户验收测试。 （该软件已通过验证和接受。）

唉，有时您只需要进行转换。但我鼓励你 A) 确保它对某人很重要，然后 B) 编写测试以证明你的报告在指定的程度上是准确的。