由于更新锁定导致的死锁问题

Question

我们遇到了一个我们试图追查的死锁问题.我有一个从Profiler生成的死锁图(xdl).它将丢失的SQL语句显示为简单的Select语句,而不是Update,Delete或Insert语句.该图显示丢失的Select语句为请求资源上的共享锁**but also owning an Update lock on a resource**.这令我感到困惑.为什么不属于Insert,Update或Delete的Select语句在资源上持有Update锁？

我应该补充一点,它所拥有的Update锁定在由失败的Select语句选择的表上.

编辑:请不要建议使用NoLock.是的,这将解决问题,但引入了一个新问题 - 脏读问题.此查询正在访问生产服务器.我真正想知道的是为什么Select语句会发出Update锁.

Answer 1

你确定SELECT 拥有 U锁吗？

如您所知,U和X锁(以及可序列化的S锁)在事务持续期间保留,而不是语句.因此,从先前执行的语句中发出写入的事务完全有可能拥有U锁.为什么它会拥有一个U锁,而不是一个X锁(即它拥有一个未升级到X的U锁)本身就是一个难题,但我可以想象这可能发生的几种方式.
因此,如果它是多语句事务的一部分,那么完全有可能拥有一个SELECT语句来拥有X/U锁.一个带有U锁的独立SELECT,我认为这有点不寻常.

典型的SELECT与UPDATE死锁发生在索引访问顺序方案中,如读/写死锁中所述.我相信你会仔细阅读死锁图,但如果不是太多问题,你能分享一下吗？

哦,顺便问一下,你考虑过读过提交的快照吗？