应该怎样做以适应PK可能溢出的情况？
不太可能，但仍有可能。我看过一个新闻选择退出表格不起作用，因为它可能有很多要求。
在申请方面可以做些什么？可以在MySQL上做些什么？
答案 0 :(得分：3)
应该怎样做以适应PK可能溢出的情况？
简单的解决方案是设计模式，以便PK的类型足够大，以至于在任何合理的用例中都不会发生溢出。
如果该假设失败则会出现问题。我可以想到一些可能的选择。
将PK类型更改为“更大”的类型，修改应用程序并迁移数据。
编写应用程序以“压缩”密钥空间;即，对于每个实时密钥，更新所有使用密钥的记录，将其替换为新密钥...从空格的开头开始。
包装密钥空间，并使用更复杂的生成器来获取检查每个候选密钥尚未使用的下一个密钥。
请注意，此类事物通常不会设计到系统中，尤其是因为很难预测并且难以测试。
答案 1 :(得分：2)
我曾处理过一个32位INT溢出的情况。这是因为应用程序意外地为每个成功的行插入跳过了1000个值。在这种情况下，应用程序达到了最高签名的INT值，并且他们无法在该表上进行任何更多插入。我被叫来帮助他们重组表以使用BIGINT主键。
但当然在之前执行此操作时，我们必须更改引用表的所有外键以使用BIGINT。因为我们不希望在主表中插入新的PK值，而这些PK值无法被其他表中的FK引用。
在BIGINT中耗尽值的范围应该比我们的生命周期更长 - 除非你每次插入一个新行时跳过十亿个数值！
我编写了一个名为pk-full-ratio的脚本，它将检查给定数据库中的每个AUTO_INCREMENT PRIMARY KEY，并计算溢出的接近程度（百分比）。