好的,所以我知道有大量文章指出我不应该使用 DOUBLE 在 MySQL 数据库上存储资金,否则我最终会遇到棘手的精度错误。重点是我不是在设计一个新的数据库,而是要求我找到优化现有系统的方法。新版本包含 783 个 DOUBLE 类型列,其中大部分用于存储金钱或计算金额的公式。
所以我对这个主题的第一个意见是我应该强烈建议在下一个版本中从 DOUBLE 转换为 DECIMAL,因为 MySQL 文档和每个人都这么说。但后来我找不到任何好的论据来证明这一建议的合理性,原因有以下三个:
- 我们不对数据库执行任何计算。所有操作均在 Java 中使用 BigDecimal 完成,MySQL 仅用作结果的普通存储。
- DOUBLE 提供的 15 位精度已经足够了,因为我们主要存储 2 位小数的金额,偶尔也存储 8 位小数的小数字作为公式参数。
- 我们在生产中拥有 6 年的记录,没有因 MySQL 端精度损失而出现任何已知错误问题。
即使在 1800 万行的表上执行操作(例如 SUM 和复杂乘法),我也无法执行缺乏精度的错误。我们实际上并没有在生产中做这类事情。我可以通过做类似的事情来显示损失的精度
SELECT columnName * 1.000000000000000 FROM tableName;
但我无法找到一种方法将其变成小数点后第二位的错误。我在互联网上发现的大多数实际问题都是 2005 年及更早版本的论坛条目,我无法在 5.0.51 MySQL 服务器上重现它们中的任何一个。
因此,只要我们不执行任何 SQL 算术操作(我们不打算这样做),仅在 DOUBLE 列中存储和检索金额是否会出现任何问题?
实际上是完全不同的。 DOUBLE 会导致舍入问题。如果你做了类似的事情0.1 + 0.2
它给你类似的东西0.30000000000000004
。我个人不相信使用浮点数学的财务数据。影响可能很小,但谁知道呢。我宁愿拥有我所知道的可靠数据,而不是近似数据,尤其是在处理货币价值时。
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)