加密货币 MySQL 数据类型？答案

【问题标题】：Crypto Currency MySQL Datatypes ?加密货币 MySQL 数据类型？
【发布时间】：2018-03-21 09:28:48
【问题描述】：

在 SQL 数据库中存储货币值时关于数据类型的臭名昭著的问题。

然而，在这些艰难时期，我们现在拥有价值高达小数点后 18 位的货币（感谢 ETH）。

这又重新提出了经典论点。

想法

选项1 BIGINT用一个大整数保存实际值，然后存储货币有多少个小数位（简单地将A除以10^B翻译）？

选项 2 Decimal(60,30) 将数据类型存储为大十进制，这不可避免地会占用大量空间。

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

我想知道人们在处理加密货币价值时的想法以及他们在使用什么。因为我不知道如何进行的最佳方法。

【问题讨论】：

赞成，但我认为这一直是处理大量交易的大型金融机构的问题。我想知道他们如何处理这件事？我的猜测是大号DECIMAL。
这个问题太宽泛了，因为答案很大程度上取决于您将用于处理数据的算法以及您需要的性能。作为一般规则，我认为基于字符串 (VARCHAR) 和使用 DECIMAL 计算的算法会很慢，但与使用 BIGINT 组合的一些快速但棘手的方法相比，可以更容易理解和DOUBLE，两个双打或其他类型。
如果您必须以与银行完全相同的方式进行舍入，那么您不仅需要正确的小数位数，还需要了解舍入规则。你真正的目标是什么？如果它正在跟踪“股票”，DOUBLE，大约 16 个有效位的精度可能绰绰有余。

【解决方案1】：

在您建议的三个中，有一个明显的最佳选择（加上 cmets 中的一个）。

BIGINT — 仅使用 8 个字节，但最大的 BIGINT 只有 19 个十进制数字；如果你除以 10¹⁸，你能表示的最大值是 9.22，这个范围不够。

DOUBLE——只有 15-17 位小数的精度；具有浮点运算的所有已知缺点。

VARCHAR — 如果您处理 18 位小数，将使用 20+ 字节；将需要常量 string↔int 转换；无法排序；无法比较；不能添加到数据库中；缺点很多。

DECIMAL(27,18) – 如果使用 MySQL，这将占用 12 个字节 (4 for each group of 9 digits)。这是一个相当合理的存储规模，并且有足够的范围来支持大至十亿或小至一卫的数量。可以在数据库中进行排序、比较、加减等，不损失精度。

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

【讨论】：

感谢您的反馈，我不确定这个问题是否会得到答案，哈哈。
DECIMAL(27,18) 将占用 20 个字节，整数部分占用 12 个字节，小数部分占用 8 个字节。对吗？
@sasa 不，DECIMAL(27,18) 共有 27 位：小数点前 9 位（4 字节）和 18 位后（8 字节），共 12 字节。
根据 Solidity 文档，声明为 uint256 的 ETH 值有 256 位无符号。这意味着 32 个字节！因此，使用上述方法可能会出现一些令人惊讶的边缘情况，尤其是在使用一些具有大量供应的代币时。