事务与另一个进程已被死锁在 lock 资源上

设table1(A,B,C)
A B C
a1 b1 c1
a2 b2 c2
a3 b3 c3

1）排它锁
新建两个连接
在第一个连接中执行以下语句
begin tran
update table1
set A=aa
where B=b2
waitfor delay 00:00:30 --等待30秒
commit tran
在第二个连接中执行以下语句
begin tran
select * from table1
where B=b2
commit tran

若同时执行上述两个语句，则select查询必须等待update执行完毕才能执行即要等待30秒

2）共享锁
在第一个连接中执行以下语句
begin tran
select * from table1 holdlock -holdlock人为加锁
where B=b2
waitfor delay 00:00:30 --等待30秒
commit tran

在第二个连接中执行以下语句
begin tran
select A,C from table1
where B=b2
update table1
set A=aa
where B=b2
commit tran

若同时执行上述两个语句，则第二个连接中的select查询可以执行
而update必须等待第一个连接中的共享锁结束后才能执行 即要等待30秒

3）死锁
增设table2(D,E)
D E
d1 e1
d2 e2
在第一个连接中执行以下语句
begin tran
update table1
set A=aa
where B=b2
waitfor delay 00:00:30
update table2
set D=d5
where E=e1
commit tran

在第二个连接中执行以下语句
begin tran
update table2
set D=d5
where E=e1
waitfor delay 00:00:10
update table1
set A=aa
where B=b2
commit tran

同时执行，系统会检测出死锁，并中止进程

 

MSSQL锁机制
分两种情况：
一、如果数据量大且多用户并发，会产生锁等待。
二、如果有其它用户同时在对这两个表做更新或删除操作，会对表下独占锁
此时你无法扫描全表，也就无法统计。独占锁和共享锁是互斥的。

如果你的数据是时时变化的，那么前后两分钟统计的数据也可能是不相同的
所以可以采用降低事务隔离等级来解决：
如：FROM mobile (NOLOCK) /  FROM mobiletype (NOLOCK)
也可以只在SQL开头指定： SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED