加密货币MySQL数据类型？

Question

在SQL数据库存储货币值时所涉及数据类型的臭名远扬的问题

然而，在这个艰难时期，我们现在有了价值高达18位小数的货币（感谢以太坊）。

这再次引发了经典争论。

想法

选项1 BIGINT 使用大整数来保存实际值，然后存储货币的小数位数（在翻译中简单地将A除以10^B）？

选项2 Decimal(60,30) 使用大型十进制数存储数据类型，这必然会占用大量空间。

选项3 VARCHAR(64) 存储在字符串中。这会对性能产生影响。

---

我想知道人们的想法，以及如果他们正在处理加密货币价值，他们使用什么方法。因为我对最佳处理方法感到困惑。

- Kevin Upton

---

已点赞，但我认为这在处理大额交易的大型金融机构中一直存在问题。我想知道他们是如何处理的？我猜测可能是使用大型“DECIMAL”。 - Tim Biegeleisen

这个问题太过宽泛，因为答案强烈依赖于您将用来处理数据的算法以及所需的性能。一般而言，我认为基于字符串（VARCHAR）和使用DECIMAL进行计算的算法会相当慢，但与某些快速但棘手的方法相比，后者使用了BIGINT和DOUBLE的组合，两个双精度浮点数或其他类型。虽然前者更容易理解。 - Binarus

如果你必须以银行的方式精确四舍五入，那么你不仅需要正确的小数位数，还需要了解舍入规则。你真正的目标是什么？如果是跟踪“股票”，具有约16个有效数字的DOUBLE精度可能已经足够了。 - Rick James

Answer 1

你提出的三种选项（以及评论中的一种）中，有一种选项是最优明显的。

BIGINT — 只需使用8个字节，但最大的BIGINT仅具有19个十进制数字；如果您除以10¹⁸，则可以表示的最大值为9.22，这不足够大。

DOUBLE — 仅具有15-17个十进制数字的精度；具有所有已知浮点数算术的缺点。

VARCHAR — 如果处理18位小数，则将使用20多个字节；需要不断进行字符串↔int转换；不能排序、比较、在数据库中添加等，有许多缺点。

DECIMAL(27,18) – 如果使用MySQL，则需要占用12个字节(每组9个数字需要4个字节)。这是相当合理的存储大小，并且具有足够的范围，以支持像1亿这样大或像1Wei这样小的量。在数据库中可以对其排序、比较、相加、相减等操作而不会失去精度。

我会使用DECIMAL(27,18)（或者如果您需要存储真正巨大的值，则使用DECIMAL(36,18)）来存储加密货币金额。

- Bradley Grainger

---

谢谢您的反馈，我不确定这个问题是否会得到答案，哈哈。 - Kevin Upton

DECIMAL(27,18)将占用20个字节，其中整数部分占用12个字节，小数部分占用8个字节。对吗？ - sasa

@sasa 不，对于 DECIMAL(27,18)，总共有27个数字：小数点前9个（4字节），小数点后18个（8字节），总共12字节。 - Bradley Grainger

根据Solidity文档，声明为uint256的以太币价值是256位无符号整数，也就是32个字节！因此，在处理一些拥有数量显著较大的代币时，使用上述数据类型可能会有一些意外的边缘情况。 - Allen Hamilton