如果表中有这么多条目，那么对于给定时间段（天，周，月，...）内的auto_increment ID，2 ^ 32不够吗？如果MySQL提供的最大数据类型还不够怎么办？
我想知道应该如何解决我的表中添加了如此多的条目，这些条目需要唯一的ID，但是我在一段时间内填满了数据类型的情况？
我怎么能在MySQL（或任何其他系统）中本地实现无限数量的唯一ID或至少使其成倍增加？
理想情况下，我希望有类似的东西
> SELECT * FROM table;
+---+------+
| a | b |
+---+------+
| 1 | 1 |
| 1 | 2 |
| 1 | 3 |
|...| .... |
|...| .... |
| 1 | 2^32 |
| 2 | 1 |
| 2 | 2 |
+---+------+
以指数方式增加条目的数量。
您如何应对这种情况？请记住-要求任何输入都必须具有唯一的ID。
您可以将BIGINT用作主键。默认情况下，这是一个64位数字。
编辑＃2：显然，我之前所说的关于更改BIGINT字节长度的说法是不正确的。 BIGINT is固定为8个字节的限制。
如果BIGINT不足以供您使用，请在表中使用它，并且当条目数量达到BIGINT边界时，创建另一个表并从0开始重新进行。现在，您将有2个表来存储相同类型的数据。
您不认为BIGINT UNSIGNED就足够了吗？范围是0-18.446.744.073.709.551.615或一年，每天（365 d / y）每天输入50.539.024.859.478.223个条目，每小时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.028年的条目。那应该足够了。
只需使用128位密钥。不需要无限数量的键，因为您很快就能允许比宇宙中原子数更多的行。 （大约256位）。
如果您有太多数据，您会遇到此问题，那么选择主键可能是您最不关心的问题。
[如果您使用的是InnoDB引擎，选择会经常搜索的主键（特别是在搜索返回很多行的地方）可能会对性能有所帮助，因为它将主键聚集在一起，从而使范围扫描效果更好。
我先移到BIGINT 2 ^ 64。 GUID是另一种选择，但是您需要自己以“某种形式”存储它们]
不要使用自动递增的主键-使用GUID或类似的词-来自维基百科文章：
虽然每个生成的GUID不是保证是唯一的，总的唯一键的数量（2 ^ 128或3.4×10 ^ 38）太大，以至于出现相同数字的可能性两次生成是无限地小。例如，考虑可观察的宇宙，其中包含约5×1022星;每个星星都可以然后有6.8×1015普遍独特GUID。
当您在键中添加另一列时，实际上将使您需要执行的索引扫描数量加倍（尽管第二列的索引要小得多）。
如前所述，对VAST数据集最好的选择是GUID（如果RDBMS本身支持它）或varchar（16）。
关于使用varchar / varbinary的好处是，如果需要，您可以在将来自动扩展列。而且不好的部分是，与整数相比，varchar / varbinary是性能较差的密钥。
我不确定如何在MySQL中自动生成它们，然后它们不一定是顺序的，但是我很确定您可以使用GUID，而不必担心它们会被填满。
您还可以将chars / varchars用于键列，并将GUID用于键。我不知道与整数主键相比是否会导致性能下降。