如何处理SQL Server死锁问题

1) 预防死锁。

这是一种较简单和直观的事先预防的方法。方法是通过设置某些限制条件，去破坏产生死锁的四个必要条件中的一个或者几个，来预防发生死锁。预防死锁是一种较易实现的方法，已被广泛使用。但是由于所施加的限制条件往往太严格，可能会导致系统资源利用率和系统吞吐量降低。

2) 避免死锁。

该方法同样是属于事先预防的策略，但它并不须事先采取各种限制措施去破坏产生死锁的的四个必要条件，而是在资源的动态分配过程中，用某种方法去防止系统进入不安全状态，从而避免发生死锁。

3)检余慧丛测死锁。

这种方法并不须事先采取任何限制性措施，也不必检查系统是否已经进入不安全区，此方法允许系统在运行过程中发生死锁。但可通过系统所设置的检测机构，及时地检测出死锁的发生，并精确地确定与死锁有关的进程和资源，然后采取适当措施，从系统中将已发生的死锁清除掉。

4)解除死锁。

这是与检测死锁相配套的一种措施。当检测到系统中已发生死锁时，须将进程从死锁状态中解脱出来。常用的实施方法是撤销或挂起一些进程，以便回收一些资源，再将这些资源分配给已处于阻塞状态的进程，使之转为就绪状态，以继续运行。死锁的检测和解除措施，有可能使系统获得较好的资源利用率和吞吐量，但在实现上难度也最大。

由上面4中处理死锁的办法看，其中检测死锁和解除死锁是Lock Monitor的事，作为DBA或数据库开发人员，处理死锁要放在预防和避免死锁上。

预防死锁

预防死锁就是破坏四个必要条件中的某一个和几个，使其不能形成死锁。有如下几种办法

1)破坏互斥条件

破坏互斥条件有比较严格的限制,在SQL Server中，如果业务逻辑上允许脏读，则可以通过将隔离等级改为未提交读或使用索引提示。这样使得读取不用加S锁，从而避免了和其它查询所加的与S锁不兼容的锁互斥，进而减少了死锁出现的概率。

2)破坏请求和等待条件

这点由于事务存在原子性，是不可破碧迅坏的，因为解决办法是尽量的减竖樱少事务的长度，事务内执行的越快越好。这也可以减少死锁出现的概率。

3)破坏不剥夺条件

由于事务的原子性和一致性，不剥夺条件同样不可破坏。但我们可以通过增加资源和减少资源占用两个角度来考虑。

增加资源：比如说通过建立非聚集索引，使得有了额外的资源，查询很多时候就不再索要锁基本表，转而锁非聚集索引，如果索引能够“覆盖(Cover)”查询，那更好不过。因此索引Include列不仅仅减少书签查找来提高性能，还能减少死锁。增加资源还可以通过SQL Server 2005之后的行版本控制进行，但这种方式并不推荐，在此不再详细讨论。

减少资源占用:比如说查询时，能用select col1,col2这种方式，就不要用select * .这有可能带来不必要的书签查找