假设你有以下代码(请忽略它很糟糕)：
BEGIN TRAN; DECLARE @id int SELECT @id = id + 1 FROM TableA; UPDATE TableA SET id = @id; --TableA must have only one row,apparently! COMMIT TRAN; -- @id is returned to the client or used somewhere else
在我看来,这不是正确管理并发性.仅仅因为您有一个事务并不意味着其他人不会读取您在更新语句之前所做的相同值.
现在,保持代码原样(我意识到这可以更好地作为单个语句处理,甚至更好地使用自动增量/标识列)什么是确定的方法,使它正确处理并发并防止允许两个客户端获得相同的竞争条件id值？
我很确定在SELECT中添加WITH(UPDLOCK,HOLDLOCK)就可以了. SERIALIZABLE transaction isolation level似乎也可行,因为它拒绝其他人阅读你所做的事情,直到tran结束(更新：这是假的.见Martin的回答).真的吗？他们俩都能同样好地工作吗？一个优先于另一个？
想象一下做一些比ID更新更合理的事情 – 一些基于你需要更新的读取的计算.可能涉及很多表,其中一些你会写,另一些你不会.这里的最佳做法是什么？
写完这个问题之后,我认为锁定提示更好,因为那时你只是锁定你需要的表格,但我很感激任何人的意见.
附：不,我不知道最好的答案,真的想要更好地理解！ 原文链接：https://www.f2er.com/mssql/79491.html
