我目前正在使用一个拥有约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仅用于保留重复项,其他表中没有对它们的引用。
我自己已经想到了两种可能的解决方案,包括它们的上行和下行;
BIGINT
并希望它不会达到最大值 虽然最大值非常大,但未来仍然有可能发生这种情况,我真的不想冒这个风险。
AUTO_INCREMENT
重置为TOP(id)
这对我来说似乎是最好的解决方案,但我感兴趣的是,如果有反对它的参数,这会将id值重置为当前表中的最大id,如果所有记录都被重新分析,它会去回到1。
我想知道我的解决方案的意见是什么,或者是否有人有更好的解决方案来解决这个问题。 提前致谢
答案 0 :(得分:1)
转到BIGINT
解决方案。真。
未签名的BIGINT
可以hold numbers与9223372036854775807一样大。
预计每周10k的比率,这意味着您的申请将在922337203685477周,或17737253917028年,或者221715673962人的生活中继续证明,预期年龄约为80岁。这大约是世界人口的三倍。
将来仍然存在打击它的风险,我真的不想冒这个风险
你可以非常肯定,当达到极限时,你的生命就结束了,解决问题的任务就是为其他人。