SQL自动增量和归档旧数据
我正在构建一个Web应用程序并且对mysql有中等程度的了解。
我正在努力解决我所看到的问题。
我的系统可能会使用 10 年。我担心自动增量值用完。
是否可以将旧数据归档或转储出系统以打开之前使用的旧自动增量值？
我读到自动增量将继续，直到达到 int 的最大值，然后抛出错误......？
我正在寻找有关此问题的任何信息。例如会计系统等其他系统如何处理此限制。
我正在使用我的自动增量
i am building a web application and have an intermidiate understanding of mysql.
i'm trying to wrap my head around a problem i see.
my system may be in usage for 10 years. i'm concerned about running out of auto increment values.
will it be possible to archive or dump old data out of the system to open up old auto increment values that were used prior?
i have read that auto increment will continue until it reaches the max value for an int then throw errors.... ?
i'm looking for any information about this issue. example how other systems like accounting systems deal with this limitations.
i'm using my auto incrememnt
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
不，您无法恢复为旧的和过时的 autoinc 值。为什么不将相应的列设置为
BIGINT？这样，您的应用程序可能可以运行数十年而不会遇到边界。我忘了告诉你，你必须在应用程序逻辑中处理新类型（我认为它是 PHP）。不要使用整数，而使用浮点数。
No, you can't revert to old and obsolete autoinc values. Why not set the corresponding column as
BIGINT? This way your app could possibly run decades without hitting a boundary.I forgot tho tell you that you would have to take care of the new type within your application logic (I presume it's PHP). Do not use integers, use float instead.
int unsigned = 每年 4.3 亿，持续 10 年
应该足够了，如果不使用 bigint unsigned :P
int unsigned = 430 million per year for 10 years
should be enough if not use bigint unsigned :P
您可以通过将 id 列更改为类似 BIGINT - 它支持高达 9223372036854775807 的数字，您永远不需要更多。不，您无法为具有该 id 的新条目释放旧 id 值。
You can increase your maximum auto increment value by changing your id column to something like a BIGINT - it supports numbers up to 9223372036854775807, you will never need more. And no, you can't free up old id values for new entries with that id.
你可以坚持使用 int 。您可以使用 GUID 列或自然键，但没有理由放弃查询性能。连接整数比连接 guid 列或复合键更快。有关类型范围的定义，请参阅此处的文档。 UNSIGNED int 或 BIGINT 是消除您对数字用完的担忧的好选择......
You can stick with int. You could go with a GUID column or natural key but there's no reason to give up the query performance. Joining on ints will be faster than joining guid columns or composite keys. See the docs here for a definition of the type ranges. UNSIGNED int or BIGINT are good bets to dispel your worries about running out of numbers...