本帖最后由 TempterX 于 2010-04-19 17:09:04 编辑

解决方案 »

  1.   

    如果是UPDATE时的WHERE里写的B>A,就不用怕并发的问题吧,只要没显式指定NOLOCK,肯定会有排它锁的
      

  2.   

    to guguda2008:   实际情况下不只要判断 a > b 这种情况。还要判断 a = b 和 a < b 分别做不同的处理。现在我就是用你的方法写成三个带where的update句子,然后用@@rowcount判断。但是这样好像效率不高。每次都要执行好几个update句子。
    to fredrickhu & sgtzzc:
      
      两位。如果我要在update前用select读取 a 和 b 的值来判断。如果利用 事务控制和锁机制 来避免问题呢?希望给个详细的代码例子啊。
      

  3.   

    加上排它锁with (xlock,rowlock)
    或 with (REPEATABLEREAD) 可重复读锁可排它锁可防止死锁,但并发性能降低,(读过后未提交事务,其它用户读不了)
    REPEATABLEREAD并发性比xlock高,但可能会造成死锁(两个用户同时读表中相同记录,两个用户都修改不了)
      

  4.   

    锁加于表后
    begin tran
     select * from 表 with (锁) where ...
     --其它处理语句
    ........
    commit tran
      

  5.   

    我觉得这些处理方式很傻,
    你不就是要根据a,b的值大小关系来更新么?
    那你就不会使用case when么?
    update 表 set a=(case when a>b then a+1 else a end) where 条件
    不就可以了么