数据库中已删除记录的数字主键是否会被重新用于未来的新记录？
例如，如果我有一个自动编号字段，我会在不指定此字段的情况下添加新记录，并让数据库引擎为我选择它。
那么，它会选择删除记录的编号吗？ 如果是，什么时候？
// SQL Server、MySQL。 //
后续问题： 当数据库引擎用完可用于主键的数字时会发生什么？
For example if I have an auto-numbered field, I add new records without specifying this field and let DB engine to pick it for me.
So, will it pick the number of the deleted record? If yes, when?
// SQL Server, MySQL. //
Follow-up question: What happens when DB engine runs out of numbers to use for primary keys?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（11）
不。 数字主键不会重复使用，除非您手动指定它们（您应该真正避免这种情况！）
NO. numerical primary keys will not reused, except you specify them manually(you should really avoid this!)
AFAIK，这可能发生在MySQL中：
InnoDB 中 AUTO_INCRMENT 处理如何工作：
服务器重新启动后。 Innodb 重用之前生成的 auto_increment 值。
：
AFAIK, this could happen in MySQL:
How AUTO_INCREMENT Handling Works in InnoDB:
After a restart of server. Innodb reuse previously generated auto_increment values.
:
取决于自动编号系统。 如果您使用任何类型的序列，则已删除记录的数量将不会被重用，因为序列不知道它们。
Depends on the auto-numbering system. If you're using a sequence of any kind, the numbers of deleted records will not get reused, as the sequence does not know about them.
一般来说，不会，这些号码不会重复使用。
然而，您可以在像 Oracle 这样的产品中指定一个循环生成并重用数字的序列生成器。
这些是否是已删除记录的数量是您的应用程序的问题。
Generally, no, the numbers are not reused.
However, you can -- in products like Oracle -- specify a sequence generator which cycles around and will reuse numbers.
Whether those are numbers of deleted records or not is your applications's problem.
这个问题需要更精确：
...“使用 Oracle 序列”
...“使用 MySQL 自动编号列”
...等等...
This question needs to be made more precise:
... "with Oracle Sequences"
... "with MySQL autonumber columns"
... etc...
只要正确创建表格，您就不会重复使用数字。
但是，您可以使用以下命令重新设置标识列（无论如何在 MSSQL 中）：
-- 输入表中最后一个有效条目的编号，而不是要使用的下一个编号
DBCC CHECKIDENT ([TableName], RESEED, [NumberYouWantToStartAt])
这当然是疯狂的......并且永远不应该这样做:)
As long as you create the table correctly you will not reuse numbers.
However you can RESEED the identity column (IN MSSQL anyway) by using the following:
-- Enter the number of the last valid entry in the table not the next number to be used
DBCC CHECKIDENT ([TableName], RESEED, [NumberYouWantToStartAt])
This is of course insane... and should never be done :)
MySQL 不会重用 ID，除非您在没有
where子句的情况下截断表或从表中删除（在这种情况下，MySQL 在内部简单地执行截断）。MySQL will not reuse IDs unless you
truncatethe table ordelete fromthe table with nowhereclause (in which case MySQL, internally, simply does atruncate).不具体。 如果从序列或自动增量标识列中读取键，则序列将直接插入并生成下一个值。 不过，您可以停用此功能（在 SQL Server 上
set Identity_insert on）并在列中放入您想要的任何数字，只要它不违反唯一性约束即可。Not specifically. If the key is being read from a sequence or autoincrementing identity column the sequence will just plug along and produce the next value. However, you can deactivate this (
set identity_insert onon SQL Server) and put any number you want in the column as long as it doesn't violate the uniqueness constraint.是的，这实际上取决于您生成 id 的方式。
例如，如果您使用 GUID 作为主键，则大多数获取随机新 Guid 的实现不太可能再次选择另一个 guid，但它会给予足够的时间，并且如果 Guid 不在表中，则插入语句将执行很好，但如果那里已经有一个 guid，您将遇到主键约束冲突。
Yeah, it really depends on the way you generate the id.
For example if you are using a GUID as the primary key, most implementations of getting a random new Guid are not likely to pick another guid again, but it will given enough time and if the Guid is not in the table the insert statement will go fine, but if there is already a guid there you will get a primary key constraint violation.
我认为 MySQL 重用 id 的“功能”是一个错误。
考虑诸如处理文件上传之类的事情。 使用数据库 ID 作为文件名是一个很好的做法：简单，没有用户提供的文件名被利用的风险等。
当涉及文件系统时，您无法真正使所有内容都成为事务性的...您必须提交数据库事务然后写入文件，或者写入文件并提交数据库事务，但是如果其中一个或两个都失败，或者您发生崩溃，或者您的网络文件系统出现故障，您可能在数据库中有有效记录，但没有文件，或没有数据库记录的文件，因为该事物不是原子的。
如果发生这样的问题，并且服务器返回时所做的第一件事就是覆盖回滚事务的 ID，从而覆盖文件，那就很糟糕了。 这些文件本来可能有用。
I consider the MySQL "feature" of reusing id's a bug.
Consider something like processing of file uploads. Using the database id as a filename is a good practice : simple, no risk of exploits with user-supplied filenames, etc.
You can't really make everything transactional when the filesystem is involved... you'll have to commit the database transaction then write the file, or write the file and commit the database transaction, but if one or both fail, or you have a crash, or your network filesystem has a fit, you might have a valid record in the database and no file, or a file without a database record, since the thing is not atomic.
If such a problem happens, and the first thing the server does when coming back is overwrite the ids, and thus the files, of rolled back transactions, it sucks. Those files could have been useful.
不，想象一下如果您的银行决定重新使用您的 account_id - arghhhh !!
no, imagine if your bank decided to re-use your account_id - arghhhh !!