sql服务器回滚
可能的重复：
即使事务回滚，SQL 标识（自动编号）也会增加
回滚也会回滚标识值吗？？？
Possible Duplicate:
SQL Identity (autonumber) is Incremented Even with a Transaction Rollback
does a rollback also rollback identity values???
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
不，也不应该……
身份的生成必须在交易之外，否则就行不通。
No, and it shouldn't...
The generation of Identities has to be outside of transactions or it wouldn't work.
回滚不会重置种子值（这意味着标识值中会有间隙）。
例如：如果插入 5 行，其标识值为：
并执行回滚，则下一个标识值仍将是
10，即使缺少 5 - 9。a rollback does not reset the seed value (which means there will be a gap in the identity values).
example: If you insert 5 rows, whose identity values are:
and do a rollback, the next identity value will still be
10, even though 5 - 9 are missing.不，这是有充分理由的。假设有两个活动交易，每个交易都使用相同的身份。假设事务 1 抓取数字 (1, 3, 4, 7, 9)，事务 2 抓取 (2, 5, 6, 8)。然后事务 2 被回滚。身份应该回滚到什么？如果身份被重置，使得“下一个”值是事务分配的第一个或最后一个值，则下一个从身份中获取数字的程序在尝试使用该数字时可能会遇到某种关键违规。因此，身份号码分配不会进行交易。
分享并享受。
No, and for good reason. Let's say there are two transactions active, each making use of the same identity. Say that transaction 1 grabs numbers (1, 3, 4, 7, 9) and transaction 2 grabs (2, 5, 6, 8). Transaction 2 is then rolled back. What should the identity roll back to? If the identity is reset so that the 'next' value is either the first or last value allocated by the transaction, the next program to grab a number from the identity would likely encounter a key violation of some variety when trying to use that number. For this reason identity number allocations are not transactioned.
Share and enjoy.
不，你不会希望它重用它们。永远不应该假设身份没有间隙（它们也不会重复用于删除）。
这些差距对任何人来说都不重要。如果有人要求使用此功能，请解释一下，手动创建 id 将需要进行广泛且昂贵的更改，并且该更改将因竞争条件而带来很大的数据完整性问题风险。此外，这种昂贵且有风险的改变绝对不会产生任何收益。系统运行速度会变慢（手动生成 id 需要更长的时间，特别是如果您要填补空白），并且如果您重复使用已删除的 id，并且存在因其他人而未删除的子记录，则数据可能会出现错位的巨大风险认为正式执行 PK/FK 关系是一个坏主意（或者只是错过了一张桌子）。这是我个人不会接受的要求。这对数据来说太危险了。
No and you would not want it to reuse them. Identities should never be assumed to have no gaps (they aren't reused for deletes either).
Nor should the gaps matter to anyone. If someone asks for this functionality explain that it will require an extensive and expensive change to manually create the ids and that change will have a lot of risk of data integrity problems due to race conditions. Further this expensive and risky change will produce absolutely no gain whatsoever. The system will work slower (it takes longer to manually generate ids espcially if you are going to fill gaps) and there is a great risk that data may get misaligned if you reuse deleted ids and there are child records that were not deleted because someone else thought formally enforcing PK/FK relationships was a bad idea (or just missed a table). This is a requirement I personally would not accept. It is a too dangerous to the data.