这种死锁的原因是什么
一个网站程序，访问比较频繁；主要是update更新数据的时候，发生“事务（进程 ID 75）与另一个进程已被死锁在 lock | communication buffer 资源上，且该事务已被选作死锁牺牲品。请重新运行该事务。”

用网上找到的一个查找死锁原因的sql试了，结果如下：

进程号SPID:55被进程号SPID:65阻塞(死锁)，其当前进程执行的SQL语法如下
EventType Parameters EventInfo
PRC Event 0 sp_cursor;1

[解决办法]
查查程序有无互相调用的情况,如A表的触发器调用B表，B表的触发器又调用C表，C表的触发器由调用A表。如果多人同时更新同一个表，不可能死锁吧
[解决办法]
是不是在修改主键信息啊
[解决办法]
ding
[解决办法]
--可以用健的存程查看死的SQL句，其行分析即可找到原因
/*--理死

查看前程,或死程,能自掉死程

因是死的,所以如果有死程,只能查看死程
然,你可以通控制,不管有有死,都只查看死程

--用示例

exec SP_Sys_LockInfo
--*/
CREATE proc SP_Sys_LockInfo
@kill_lock_spid bit=0, --是否掉死的程,1 掉, 0 示
@show_spid_if_nolock bit=1 --如果有死的程,是否示正常程,1 示,0 不示
as
declare @count int,@s nvarchar(4000),@i int
select id=identity(int,1,1),,
程ID=spid,程ID=kpid,程ID=blocked,料ID=dbid,
料名=db_name(dbid),用ID=uid,用名=loginame,累CPU=cpu,
登=login_time,打事=open_tran, 程=status,
工作站名=hostname,用程式名=program_name,工作站程ID=hostprocess,
功能名=nt_domain,卡位址=net_address
into #t from(
select = '死的程 ',
spid,kpid,a.blocked,dbid,uid,loginame,cpu,login_time,open_tran,
status,hostname,program_name,hostprocess,nt_domain,net_address,
s1=a.spid,s2=0
from master..sysprocesses a join (
select blocked from master..sysprocesses group by blocked
)b on a.spid=b.blocked where a.blocked=0
union all
select '|_牲品_> ',
spid,kpid,blocked,dbid,uid,loginame,cpu,login_time,open_tran,
status,hostname,program_name,hostprocess,nt_domain,net_address,
s1=blocked,s2=1
from master..sysprocesses a where blocked <> 0
)a order by s1,s2

select @count=@@rowcount,@i=1

if @count=0 and @show_spid_if_nolock=1
begin
insert #t
select = '正常的程 ',
spid,kpid,blocked,dbid,db_name(dbid),uid,loginame,cpu,login_time,
open_tran,status,hostname,program_name,hostprocess,nt_domain,net_address
from master..sysprocesses
set @count=@@rowcount
end

if @count> 0
begin
create table #t1(id int identity(1,1),a nvarchar(30),b Int,EventInfo nvarchar(3500))
if @kill_lock_spid=1
begin
declare @spid varchar(10),@ varchar(10)
while @i <=@count
begin
select @spid=程ID,@= from #t where id=@i
insert #t1 exec( 'dbcc inputbuffer( '+@spid+ ') ')
if @= '死的程 ' exec( 'kill '+@spid)
set @i=@i+1
end
end
else
while @i <=@count
begin
select @s= 'dbcc inputbuffer( '+cast(程ID as varchar)+ ') ' from #t where id=@i
insert #t1 exec(@s)
set @i=@i+1
end
select a.*,程的SQL句=b.EventInfo
from #t a join #t1 b on a.id=b.id
end


[解决办法]
其实所有的死锁最深层的原因就是一个:资源竞争
表现一:
一个用户A 访问表A(锁住了表A),然后又访问表B
另一个用户B 访问表B(锁住了表B),然后企图访问表A
这时用户A由于用户B已经锁住表B，它必须等待用户B释放表B,才能继续，好了他老人家就只好老老实实在这等了
同样用户B要等用户A释放表A才能继续这就死锁了
解决方法：
这种死锁是由于你的程序的BUG产生的，除了调整你的程序的逻辑别无他法

仔细分析你程序的逻辑，
1：尽量避免同时锁定两个资源
2: 必须同时锁定两个资源时，要保证在任何时刻都应该按照相同的顺序来锁定资源.

表现二:
用户A读一条纪录，然后修改该条纪录
这是用户B修改该条纪录
这里用户A的事务里锁的性质由共享锁企图上升到独占锁(for update),而用户B里的独占锁由于A有共享锁存在所以必须等A释
放掉共享锁，而A由于B的独占锁而无法上升的独占锁也就不可能释放共享锁，于是出现了死锁。
这种死锁比较隐蔽，但其实在稍大点的项目中经常发生。
解决方法:
让用户A的事务（即先读后写类型的操作),在select 时就是用Update lock
语法如下：
select * from table1 with(updlock) where ....

[解决办法]
记号
[解决办法]
联机帮助－－死锁，有介绍
[解决办法]
mark
[解决办法]
谢谢 rockyljt(江) ( )提供的存储过程
[解决办法]
mark
[解决办法]
看LZ上面出的错，这个时候死锁已经解开了，只是其中的一个事务需要重新提交一次，对数据还是没有影响的，也不影响其他人的操作，

死锁的原因其实很简单，就是两个事务互相等，然后就死锁了，不过SqlServer做的比较好，每次死锁过不了多长时间就自动牺牲掉其中一个事务，然后一切恢复正常


关键是要找出引起死锁的语句，然后想办法优化，避免死锁，这个还是有点难度的，我每次都是用 SQL Server Profiler 去跟踪死锁附近的语句，然后分析，有点麻烦的，
不过确实有必要跟踪一下代码，死锁是很好解的，可是每次等出现了再去解一点意义都没有，何况SqlServer已经能自己帮你解了