Question

如果您在表格中有这么多条目，那么在给定时间段内（天，周，月......），2 ^ 32对于您的auto_increment ID是不够的呢？如果MySQL提供的最大数据类型不够，该怎么办？

我想知道我应该如何解决我的表中添加了如此多条目需要唯一ID的情况，但是我在一段时间内填写了我的数据类型？

我如何能够在MySQL（或任何其他系统）内部实现无限量的唯一ID，或者至少以指数方式增加它？

理想情况下，我会期待像

这样的东西

> SELECT * FROM table;

+---+------+
| a |  b   |
+---+------+
| 1 |  1   |
| 1 |  2   |
| 1 |  3   |
|...| .... |
|...| .... |
| 1 | 2^32 |
| 2 |  1   |
| 2 |  2   |
+---+------+

以指数方式增加参赛人数。

你如何应对这种情况？请记住 - 要求是为任何条目提供唯一ID。

Answer 1

你不认为BIGINT UNSIGNED就足够了吗？这是一个0 - 18.446.744.073.709.551.615的范围，或一年50.539.024.859.478.223条目每天（365 d / y），每小时2.105.792.702.478.259条目，每分钟35.096.545.041.304条目或每秒584.942.417.355。

With assumed 600 writes per second (without any reads)你可以以完全写入速度写入条目974。904。08年。那应该够了。

Answer 2

您可以使用BIGINT作为主键。默认情况下，这是一个64位数字。

编辑＃2：显然我之前所说的关于改变BIGINT字节长度的内容是不正确的。 BIGINT 固定为8字节限制。

Answer 3

只需使用128位密钥即可。不需要无限数量的键，因为您可以非常快速地允许更多行，而不是宇宙中的原子数。（大约256位）。

Answer 4

如果您有太多数据可以解决此问题，那么选择主键可能是您最不关心的问题。

如果您正在使用InnoDB引擎，那么选择您经常搜索的主键（特别是在搜索返回多行的情况下）可能有助于提高性能，因为它会聚集主键，这使得范围扫描更好。

Answer 5

我首先转向BIGINT 2 ^ 64。 GUID将是另一种选择，但您需要以“某种形式”

自行存储这些选项

Answer 6

不要使用自动增量主键 - 使用GUID或类似的 - 来自维基百科文章：

虽然每个生成的GUID都不是保证是独一无二的，总数唯一键的数量（2 ^ 128或 3.4×10 ^ 38）是如此之大，以至于相同数量的概率生成两次是无穷小的小。例如，考虑一下可观察的宇宙，其中包含约5×1022颗星;每个明星都可以然后有6.8×1015普遍独特的GUID。

Answer 7

当您向密钥添加另一列时，您实际上需要将索引扫描的数量增加一倍（尽管第二列的索引要小得多）。

如前所述，VAST数据集的最佳选择是GUID（如果您的RDBMS本身支持它）或varchar（16）。

使用varchar / varbinary的好处是，如果需要，您可以在将来自动扩展列。糟糕的是，与整数相比，varchar / varbinary是一个表现不佳的密钥。

Answer 8

我不确定如何在MySQL中自动生成它们，然后，它们不一定是顺序的，但我很确定你可以使用GUID而不必担心它们会填满。< / p>

Answer 9

您还可以为键列使用chars / varchars，并为键使用GUID。我不知道与整数主键相比，这是否会导致性能损失。

Answer 10

如果BIGINT不足以供您使用，请在您的表中使用它，并且当条目数量达到BIGINT边界时，创建另一个表并从0开始重新开始。现在您将有2个表来存储相同类型的数据

如果2 ^ 32还不够怎么办？

10 个答案: