【发布时间】：2011-10-31 20:08:08
【问题描述】：
似乎BIGINT 是 MySQL 上可用的最大整数，对吧？
例如，当您需要存储 BIGINT(80) 时该怎么办？
为什么在某些情况下，例如 Twitter API 文档中的某处，他们建议我们将这些大整数存储为 varchar？
选择使用一种类型而不是另一种的真正原因是什么？
【问题讨论】：
-
BIGINT 根据定义限制为 8 个字节。
【发布时间】：2011-10-31 20:08:08
【问题描述】：
大整数实际上并不限于 20 位，它们仅限于可以用 64 位表示的数字（例如，数字 99,999,999,999,999,999,999 不是有效的大整数，尽管它有 20 位长） .
你有这个限制的原因是底层硬件可以相对快速地操作原生格式整数，而数字的文本版本（往往）需要一次处理一个数字。
如果您想要一个大于最大 64 位无符号整数 18,446,744,073,709,551,615 的数字，则需要将其存储为 varchar（或其他文本字段）并希望您不需要做太多数学运算对其进行操作。
或者，您可以查看具有较大范围但精度较低的浮点数，或者应该能够为您提供 65 位整数值的十进制数，以 decimal(65,0) 作为列类型。
【讨论】：
-
哪个最适合
ORDER和WHERE语句？ （使用正确设置的索引）。例如SELECT column1 FROM tableA WHERE mybigint > N ORDER BY date LIMIT 100000。在这种情况下，用于对结果进行分页。 -
@Keyne，十进制值可以正常工作，但可能比原始整数类型慢。速度的层次结构可能是各种原始积分、小数、零对齐的 varchar 和不合理的 varchar（从最快到最慢），但你不应该相信网上一些 yobbo 的建议，即使是我 :-) 测量，不要猜猜。然后使用提供所需范围的最快速度。具体来说，如果您需要 80 位数字，请使用两端对齐的 varchars（例如，将 42 存储为
0000000000...000000042）。 ... -
... 对于 25 位数字，可能是十进制 (25,0)。对于 19 位数字，bigint。等等。您的架构不会永远锁定。如果在某个时刻，您需要从 19 位移动到 25 位，那么您在该点进行从 bigint 到 decimal 的更改，否则 YAGNI 原则可能适用。
您可以指定 numeric(65,0)，但如果您需要变大，则需要一个 varchar。
选择一个而不是另一个的原因是使用、效率和空间。使用 int 比使用 bigint 更有效，我相信，如果您需要对其进行数学运算，则使用 numeric。
【讨论】：
如果您想要最大的存储效率，可以将大整数存储为an arbitrary binary string。
但我不确定这是否值得，因为您还必须在应用程序中处理超过 64 位整数，这也是 not the thing you want to do 没有充分理由。
最好保持简单并使用varchar。
【讨论】：
BIGINT 根据定义限制为 8 位。 DECIMAL 类型的最大位数为 64。您必须使用 VARCHAR 来存储更高精度的值，并注意这些值没有直接的数学运算。
【讨论】：