在的文章里，我想谈下SQL Server里如何处理死锁。当2个查询彼此等待时会发生死锁，没有一个查询可以继续它们的操作。首先我想给你大致讲下SQL Server如何处理死锁。后我会展示下SQL Sever里特定的死锁类型，还有你如何避免和解决它们。
　　死锁处理
　　死锁的好处是SQL Server自动检测并解决它们。为了解决死锁，SQL Server需要回滚2个事务中便宜的那个。在SQL Server上下文中，便宜的事务是写入事务日志更少字节的那个。
　　SQL Server在后台进程中实现死锁检测称为死锁监控（Deadlock Monitor）。这个后台进程每5秒钟运行一次，为死锁检查当前锁定情况。在坏的情况中，因此一个死锁不应该超过5秒。这个查询会回滚并收到1205错误号。死锁的好事是你可以完整从错误情况下还原，不需要用户的任何干预。一个聪明的开发者必须按下列步骤来从死锁中恢复：
　　· 当异常抛出时，检查1205错误号
　　· 暂时停止程序，给其他查询时间来完成它的事务并释放它获得的锁
　　· 重新提交查询，即被SQL Server回滚的。
　　重新提交查询后，这个查询应该继续执行，没有任何问题，因为其它查询已经完成它的事务。当然你应该保持再次发生死锁的跟踪，这样的话，你不用反复重试你的事务。
　　你可以用多种方法来故障排除死锁。SQL Server Profiler提供Deadlock Graph事件，一旦死锁检测到会发生。如果你在SQL Server 2008或更高，你可以使用故障排除来故障排除死锁场景。扩展事件提供你system_health事件会话，它跟踪自SQL Server上次重启后发生过的死锁。还有启用1222跟踪标记，SQL Server会把死锁信息写入错误日志。
　　死锁类型
　　在SQL Server里会发生各种类型的死锁。在这一部分我想进一步谈下常见的几个。
　　几乎每个SQL Server我看到典型的的死锁是的书签查找死锁，当你有同时对聚集和非聚集索引读写活动时发生。它基本上是因为不好的索引设计造成的。在我作日常SQL Server的故障排除重，我可以说所有的死锁，至少有90%可以通过更好的索引设计来解决。书签查找死锁可以通过提供覆盖非聚集索引轻松解决。
　　另一个常见的死锁是所谓的循环死锁（Cycle Deadlock），这里你的每个查询用不同的顺序访问表。为了避免这个特定的死锁，你要确保每个查询用同样的顺序访问表。在SQL Server里会发生的有意思的死锁是所谓的内部并行死锁（Intra-Parallelism Deadlock），这里平行的运算符在各自的线程内部死锁。下图展示了一个典型死锁图。

　　图片本身是一个艺术品，它因触发SQL Server里的BUG而发生。遗憾的是，这个BUG不会被微软修正，因为它引入回归的可能性。因此你要确保引起这个死锁的查询，要在SQL Server里单线程运行。你可以通过多个选项来实现单线程执行：
　　· 在你的索引策略上下功夫，这样的话查询的花费会在当前并行阈值下（默认为5）
　　· 使用MAXDOP 1查询提示，来提示SQL Server以单线程运行你的问题查询
　　另一个死锁的疗法是启用乐观并发，尤其是提交读快照隔离（Read Committed Snapshot Isolation (RCSI)），他对你的程序是完全透明的。使用乐观并发，共享锁消失，这意味着在SQL Server里你可以避免大量的典型锁。
　　小结
　　死锁是SQL Server通过回滚便宜的事务自动处理。然而你要尽可能小的确保死锁，因为每个回滚的死锁都会给你的终端用户带来不好的影响。死锁可以通过好的索引策略来避免，另外使用乐观并发也是应付它们的药。