如何处理PK溢出？

应该如何处理PK可能溢出的情况？如何处理PK溢出？

这是不可能的，但仍然有可能。我看到一个通讯退出表单不起作用，因为它可能有很多请求。

在应用程序端可以做些什么？ MySQL可以做什么？

2013-03-04 James P.

如果您担心，您可以使用'bigint'，这是不太可能超过其最大值 – iTech 2013-03-04 05:22:59

是的，这是一个实际的解决方案。这里的关键字不太可能。像地球一样突然成为星际联邦的一部分，并且每年都必须处理来自外太空的数十亿人的访问：p。 – 2013-03-04 05:49:34

在现实生活中，可能发生的情况是数据库是由外部公司设计的，直到公司突然意识到某件事情出错为止。在十年或更长的时间里，这不太可能。这就是为什么我很好奇看到的是，如果有人有另一种方式解决这个问题的经验。说，通过检索未使用的PK值，使用另一个表或不同的东西。在理想条件下，实际上可能是在数据库的整个生命周期中保持一颗眼睛，这是开发团队和数据库管理员不时处理的事情。 – 2013-03-04 05:51:41

应该如何处理PK可能溢出的情况？

简单的解决方案是设计架构，以便PK的类型足够大，以至于在任何合理的用例中溢出都不会发生。

如果这种假设失败，那么你有一个问题。我可以想到一些可能的选择。

将PK类型更改为“更大”的类型，修改应用程序并迁移数据。
写一个应用程序来“紧凑”的关键空间;即对于每个活动密钥，使用新密钥更新所有使用该密钥的记录，从空间的开始开始。
包装密钥空间，并使用更复杂的生成器获取下一个密钥，该密钥检查每个候选密钥是否已被使用。

注意，这种事情通常不会设计成一个系统，这不仅是因为它是很难预料和难以测试。

来源

2013-03-04 06:06:28

我曾在一个32位INT溢出的情况下工作。这是因为该应用程序意外地为每个成功的行插入跳过了1000个值。在这种情况下，应用程序达到了最高的已签名INT值，并且他们无法在该表上再插入任何插入内容。我被调用来帮助他们重构表格以使用BIGINT主键。

但是当然之前这样做，我们必须改变引用表的所有外键以使用BIGINT。因为我们不想在主表中插入一个新的PK值，而这个主表不能被其他表中的FK引用。

应该花费比我们的生命更长的时间来耗尽BIGINT中的值范围 - 除非每次插入新行时都跳过十亿个值！

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

来源

2013-03-04 06:28:14

为您的脚本+1。 – kwelsan 2013-03-04 10:46:05

如何处理PK溢出？

回答

相关问题