使用标识列来确定行创建的顺序是一个不好的做法吗？
如果标识列被重新播种，那么它不能用于确定行插入的顺序，但我没有理由重新播种身份。
我是否有任何理由不应该使用标识列来确定创建顺序？
Possible Duplicate:
Can I use a SQL Server identity column to determine the inserted order of rows?
If an identity column is reseeded, then it can not be used be used to determine the order of row insertion, but I have no reason to ever reseed the identity.
Are there any reasons why I should not use the identity column to determine the order of creation?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
因为它不可靠是我不会使用它的原因。您可能有两个进程同时请求身份值，进程 1 获取第一个值，进程 2 获取第二个值，但进程 2 实际上较早完成了事务，因此较早插入。如果您想了解记录实际插入的顺序，则插入日期的日期时间字段是唯一可靠的选择。
Because it wouldn't be reliable would be the reason I would not use it. You might have two processes ask simultaneously for identity values and process 1 got the first value and process 2 got the second value but process 2 actually finished the transaction earlier and thus was inserted earlier. A datetime field for date inserted is the only reliable choice if you want to know the order that records were actually inserted.
这不被认为是一个好的做法。例如，在某些服务器中，在同时事务中对表进行插入的两个进程可能会分配有大块 id，因此从一个事务插入的任何行的 id 都小于从另一事务插入的任何行的 id。此外，这有时会导致 id 序列出现间隙。并且还可能发生其他意想不到的情况。
简而言之，自动增量 id并不总是保证是连续且升序的序列。
It is not considered a good practice. For example, two processes doing inserts on a table in simultaneous transactions can in some servers have chunks of ids assigned to them, so any row inserted from one transaction will have a lesser id than any row inserted from the other transaction. Also, this can sometimes cause gaps in sequence of ids. And there may be also other scenarios something unexpected might happen.
In short, autoincremented ids are not always guaranteed to a be a continuous and ascending sequence.