2条update也会死锁?

Question

--把它放到事务中,加排它锁,试试SET TRANSACTION ISOLATION LEVEL REPEATABLE READ
begin tran
update salesdetail  WITH (XLOCK) set lot_no='WO4J2284',expiry_date=NULL where id=456001
commit tranSET TRANSACTION ISOLATION LEVEL REPEATABLE READ
begin tran
update salesdetail  WITH (XLOCK) set lot_no='WO5D2053',expiry_date=NULL where id=458940
commit tran

Answer 1

这个是不会的,注意一下set implicit_transactions 
这个应该是由程序操作的,所以不太可能,看看还有没有其他因素.

Answer 2

这是有可能的.例如, 当你的事务隔离级别设置在 Repeatable READ 或者以上时.由于执行UPDATE前会对读取的记录进行SELECT, 然后才会 UPDATE.
对于用户A的UPDATE语句, 在SELECT时, 会对检索的记录下共享锁,  UPDATE会再共享锁转换为独占锁. 由于事务隔离级别在在 Repeatable READ (或者以上), 因此在SELECT完成之后, UPDATE之前, 共享锁会一直保持
这个时候如果用户B的UPDATE语句也开始扫描记录, 并且对用户A扫描过已经下了共享锁的记录再次下共享锁(共享锁不是互拆的), 此时会导致两个用户的共享锁都无法转换成独占锁, 这样两个用户都无法完成UPDATE, 这就造成了死锁.如果两条UPDATE同时执行,

Answer 3

一般来说, UPDATE中的SELECT时间都会很少, 所以楼主的死锁一般都不会发生, 但绝大不能排除不发生的情况.

Answer 4

zjcxc(邹建) 
什么时候出锁定的书，我买了你的书呢老大，锁是个大问题：（

Answer 5

自己UP一下，用XLOCK？？？有好多这种存储过程，代价好象太大了。

Answer 6

-_-~~~ 是不是用xlock 就可以搞定的说?会不会开消太大?

Answer 7

偶尔死锁是正常的，也是不可能避免的。你的2个进程间隔时间太久了，不太可能是这二个进程死锁的,因为系统很快可以判定2个进程是否死锁，从而牺牲其中一个进程。这个时间通常是60秒钟以内。当然这2条语句是有可能互相死锁的，但你可能没正确抓到当时的语句。--------------------------
http://chinadba.cn
深圳骄子数据库服务网
最具实战经验的数据库优化、管理、设计、培训。