我目前正在使用一个包含大约 10.000+ 条记录的数据库,并且还在增长。这是一个带有维护日志的数据库,我在其上进行一些分析以提取有关维护的一些数据。分析结果存储在同一数据库中的不同表中。
维护表:
------------------------------------------
|id remainingdata
|1 testing
|2 alsotesting
|3 testing1
分析结果表:
------------------------------------------
|id maintenanceid remainingdata
|1 1 result1
|2 1 result2
|3 2 result3
|4 3 result4
|5 3 result5
日志记录可以在执行分析后更新,因此可以重新进行分析。重新分析维护记录时,将从表中删除分析的所有记录(包含维护记录的外键)并重新输入。因此,假设我重新分析了所有 3 条维护记录。我的结果表现在如下所示;
------------------------------------------
|id maintenanceid remainingdata
|6 1 result1
|7 1 result2
|8 2 result3
|9 3 result4
|10 3 result5
我面临的问题是,当每周删除并输入 10.000+ 条记录时,AUTO_INCREMENT
数字很快就会变得非常高。而且由于我想将来证明我的数据库,我需要找到这个问题的解决方案。
注意:结果表中的 id 仅用于保留重复项,其他表中没有对它们的引用。
我自己想到了 2 种可能的解决方案,既有优点也有缺点;
- 将 Pk 更改为
BIGINT
并希望它不会达到最大值
虽然最大值非常大,但将来仍有达到它的风险,我真的不想有这种风险。
- 删除任何记录后,将
AUTO_INCREMENT
重置为TOP(id)
这对我来说似乎是最好的解决方案,但如果有反对它的论据,我很感兴趣,这会将 id 值重置为表中当前的最大 id,如果重新分析所有记录,它将返回到 1。
我想知道对我的解决方案有什么意见,或者是否有人对这个问题有更好的解决方案。 提前致谢
选择BIGINT
解决方案。真。
无符号BIGINT
可以容纳大至 9223372036854775807 的数字。
预期费率为每周 10k,这意味着您的应用程序在 922337203685477 周或 17737253917028 年内或连续221715673962人的生命中具有前瞻性,预计每人年龄约为 80 岁。这大约是世界人口的三倍。
将来仍有打击的风险,我真的不想有这种风险
你可以非常肯定,当达到极限时,你的生命就结束了,解决问题的任务是别人的。