我目前正在使用一个关于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日志记录可以在分析完成后更新,因此可以重新进行分析。当重新分析维护记录时,分析的所有记录(包含维护记录的外键)将从表中删除并重新输入。因此,假设我重新分析了所有三个维护记录。我的结果表现在看起来像这样;
------------------------------------------
|id maintenanceid remainingdata
|6 1 result1
|7 1 result2
|8 2 result3
|9 3 result4
|10 3 result5我面临的问题是,当10.000+记录被删除并可能每周输入时,AUTO_INCREMENT的数量很快就会变得很高。因为我希望将来能证明我的数据库,所以我需要找到一个解决这个问题的方法。
注意:结果表中的id仅用于保存副本,其他表中没有对它们的引用。
我自己想出了两种可能的解决方案,既有优点,也有缺点;
BIGINT 将Pk改为,并希望它没有命中maxvalue虽然最大值很大,但在未来还是有可能击中它的,我真的不想有这个风险。
AUTO_INCREMENT 重置为 TOP(id)这似乎是最好的解决方案,但我感兴趣的是,如果有反对它的论点,这将把id值重置为当前在表中的最大id,如果所有记录被重新分析,它将返回到1。
我想知道关于我的解决方案的意见是什么,或者是否有人有更好的解决这个问题的办法。提前感谢
发布于 2017-06-09 09:00:03
使用BIGINT解决方案。真的。
一个未签名的BIGINT可以持有数高达9223372036854775807。
预计每周10,000,这意味着你的申请是未来的证明922337203685477周,或17737253917028岁,或221715673962人的生活顺序,预期年龄约80岁的人。这大约是世界人口的三倍。
将来还是有撞它的危险,我真的不想冒这个险
你可以确信,当你达到极限时,你的生命就结束了,解决问题的任务是由别人来完成的。
https://stackoverflow.com/questions/44452930
复制相似问题