在另一方释放资源前，会话1和会话2都不可能继续。所以，SQL Server会选择死锁中的一个会话作为“死锁牺牲品”。 注意：死锁牺牲品的会话会被杀死，事务会被回滚。 注意：[b]死锁[/b]与正常的[url=http://www.cnblogs.com/downmoon/archive/2011/02/18/1957913.html][b]阻塞[/b][/url]是两个经常被混淆的概念。 发生死锁的一些原因： 1、应用程序以不同的次序访问表。例如会话1先更新了客户然后更新了订单，而会话2先更新了订单然后更新了客户。这就增加了死锁的可能性。 2、应用程序使用了长时间的事务，在一个事务中更新很多行或很多表。这样增加了行的“表面积”，从而导致死锁冲突。 3、在一些情况下，SQL Server发出了一些行锁，之后它又决定将其升级为表锁。如果这些行在相同的数据页面中，并且两个会话希望同时在相同的页面升级锁粒度，就会产生死锁。 [b]一、[/b][b]使用 SQL Server Profiler 分析死锁[/b]  [url=http://msdn.microsoft.com/zh-cn/library/ms188246.aspx]http://msdn.microsoft.com/zh-cn/library/ms188246.aspx[/url] [b]二、使用跟踪标志位找出死锁[/b] 本文主要介绍使用DBCC TRACEON、DBCC TRACEOFF和DBCC TRACESTATUS命令来确保死锁被正确记录到SQL Server Management Studio SQL日志中。这些命令用来启用、关闭、和检查跟踪标志位的状态。 ■[b] [/b][b]DBCC TRACEON，[/b]启用跟踪标志位。用法：DBCC TRACEON ( trace# [ ,...n ][ , -1 ] ) [ WITH NO_INFOMSGS ] 详细参看 MSDN:[url=http://msdn.microsoft.com/zh-cn/library/ms187329.aspx]http://msdn.microsoft.com/zh-cn/library/ms187329.aspx[/url] ■[b] [/b][b]DBCC TRACESTATUS，[/b]检查跟踪标志位状态。用法：DBCC TRACESTATUS ( [ [ trace# [ ,...n ] ] [ , ] [ -1 ] ] ) [ WITH NO_INFOMSGS ] 详细参看 MSDN:[url=http://msdn.microsoft.com/zh-cn/library/ms187809.aspx]http://msdn.microsoft.com/zh-cn/library/ms187809.aspx[/url] ■[b] [/b][b]DBCC TRACEOFF，[/b]关闭跟踪标志位。用法：DBCC TRACEOFF (trace# [ ,...n ] [ , -1 ] ) [ WITH NO_INFOMSGS ] 详细参看 MSDN:[url=http://msdn.microsoft.com/en-us/library/ms174401.aspx]http://msdn.microsoft.com/en-us/library/ms174401.aspx[/url] 下面我们模拟一个死锁： 在第一个SQL查询窗口执行：