SQL 2008 R2 deadlock

我们在一个项目中遇到两个w3wp进程在更新同一个表的同一个record记录的时候，我们就发现了deadlock，但没有深入地去看deadlock发生的地方。

会不会比这个更悲剧，是在更新同一个表的时候就发生问题了？

 

 

1.       SQL Server的加锁数量、以及顺序，跟语句的执行计划有关系。

     ==== 语句的执行计划..... ....

 

2.       表格上的索引越多、数据类型越复杂，执行计划也会越复杂，从而导致遇到阻塞或者死锁的几率增加。

     ==== 数据类型越复杂........

3.       消除死锁，可以先检查语句的执行计划，从调整执行计划入手，引导SQL Server申请比较少的锁。

==================================================================难道真的不支持简单的同表不同记录的访问么？

SQL Server 2008 R2 太容易出现死锁了，无语了。

做了个简单例子测试一下：

1.建一个测试表：

 CREATE TABLE [dbo].[LockTest](
    [ID] [int] NULL,
    [Name] [nvarchar](10) NULL
) ON [PRIMARY]

GO

随便插入2条记录，然后，打开SSMS，新建2个查询，同时执行下面的代码，模拟2个并发线程更新同一张表，不同记录的情况：

set transaction isolation level serializable
declare @count int
declare @tranname varchar( 10)
set @count = 1
while( @count < 10)
begin
set @tranname = ' B ' + convert( varchar, @count)
begin tran @tranname
    update dbo.LockTest set Name = ' BBBB ' where ID = 2;
    waitfor delay ' 00:00:02 '
commit tran @tranname
set @count = @count + 1   
end

set transaction isolation level serializable
declare @count int
declare @tranname varchar( 10)
set @count = 1
while( @count < 10)
begin
set @tranname = ' A ' + convert( varchar, @count)
begin tran @tranname
    update dbo.LockTest set Name = ' aaa ' where ID = 1
    waitfor delay ' 00:00:02 '
commit tran @tranname
set @count = @count + 1   
end

按道理，这不应该造成死锁，顶多互相阻塞一下而已，但事实上，确引发了死锁。

(1 行受影响)
commit tran :A1
begin tran :A2
消息 1205，级别 13，状态 18，第 10 行
事务(进程 ID 56)与另一个进程被死锁在 锁 资源上，并且已被选作死锁牺牲品。请重新运行该事务。

 

http://blogs.msdn.com/b/apgcdsd/archive/2012/02/28/sql-server-deadlock.aspx  --专业team的输出