选择查询的事务死锁

郑永生

有时，对于仅作为Select查询的存储过程，会出现以下错误： Transaction (Process ID 91) was deadlocked on
lock
我最初的理解是，选择查询不会锁定表，也不会导致死锁，即使它试图查询的表正在被另一个进程更新/锁定，但似乎选择查询会导致死锁，因为出色地。
4 c9 K# H6 r: J% J$ i如果我将隔离级别设置为查询未提交，那可以解决问题吗？
               
解决方案:
3 \/ C" W' T$ ~# s               
* n" }5 F3 Z  z7 M, A% j

               
我的初步理解是，Select查询不会锁定表，也不会导致死锁
0 W5 w2 K- x' ?8 W9 w* R
  K) u, B' x4 N+ I- W3 P这种理解是错误的。SELECT查询在其分析的行上使用共享锁。共享锁可能与更新/删除/插入语句中的排他锁冲突。两个SELECT语句不会死锁，但是SELECT可以通过UPDATE死锁。当发生这种死锁时，SELECT通常是牺牲品，因为它没有执行任何更新，因此总是会丢失抽签。
- H# D$ u- X6 d; u+ y与任何死锁一样，您需要发布所涉及表的确切架构，确切的T-SQL语句和死锁图。请参阅如何：保存死锁图（SQL Server
. L; [$ e% W( Q5 n1 }0 v3 {7 }' dProfiler）。通过此信息，您可以获取有关如何修复死锁的指导。