java - 如何处理 PK 溢出？

Question

应该怎么做才能适应 PK 可能溢出的情况？

这不太可能，但仍有可能。我看到一个时事通讯选择退出表单不起作用，因为它可能有很多请求。

应用端可以做什么？在 MySQL 上可以做什么？

Answer 1

应该怎么做才能适应 PK 可能溢出的情况？

简单的解决方案是设计模式，使 PK 的类型足够大，以至于在任何可能的用例中都不会发生溢出。

如果该假设失败，那么您就有问题了。我能想到一些可能的选择。

• 将PK类型更改为“更大”的类型，修改应用程序并迁移数据。

• 编写应用程序来“压缩”密钥空间；即对于每个活动密钥，更新所有使用该密钥的记录，用新密钥替换它......从空间的开头开始。

• 包装密钥空间，并使用更复杂的生成器来获取下一个密钥，以检查每个候选密钥是否尚未使用。

---

请注意，这种东西通常不会设计到系统中，尤其是因为它难以预测和测试。

Answer 2

我曾处理过一个 32 位 INT 溢出的案例。这是因为应用程序不小心为每个成功的行插入跳过了 1000 个值。在这种情况下，应用程序达到了最高的有符号 INT 值，他们不能再对该表进行任何插入。我被要求帮助他们重组表以使用 BIGINT 主键。

但当然，在这样做之前，我们也必须更改引用表的所有外键以使用 BIGINT。因为我们不希望在主表中插入一个新的 PK 值，该值无法被其他表中的 FK 引用。

用完 BIGINT 中的值范围应该比我们的生命还要长——除非您每次插入新行时跳过十亿个值！

我编写了一个名为pk-full-ratio的脚本，它将检查给定数据库中的每个 AUTO_INCREMENT PRIMARY KEY，并计算它与溢出的接近程度（百分比）。