1.假设有一个事务A

-----事务A------- 
begin tran 
update [TestDB].[dbo].tb_score set score=score+1 where id=3 
   waitfor delay '00:00:10'   --延迟10秒读取 
SELECT *  FROM [TestDB].[dbo].tb_score 
commit TRANSACTION


它会运行10s左右，主要是更新表tb_score。在这10s期间，有语句对该表做查询。

SELECT *  FROM [TestDB].[dbo].tb_score

该语句会被阻塞，因为update会默认加上共享锁，直到10s后，事务A提交后才能查出结果。

以上语句就等介于下面的语句，因为事务隔离级别READ COMMITTED是SQLServer的默认设置。

SET TRANSACTION ISOLATION LEVEL 
READ committed 
begin tran 
SELECT *  FROM [TestDB].[dbo].tb_score 
commit TRANSACTION


此处，值得注意的事情是，在事务A中当update语句更新的时候，如果要更新的目标值=现在的值，比如，在id=3的记录，score已经等于100了的情况下，语句如果是update [TestDB].[dbo].tb_score set score=100 where id=3。那么执行SELECT *  FROM [TestDB].[dbo].tb_score将不被阻塞。原因猜测是sql不对这种实际不做更改的Update语句加锁

     

2.还是以上事务A

把查询语句改为如下

语句B：

SET TRANSACTION ISOLATION LEVEL 
READ uncommitted 
begin tran 
SELECT *  FROM [TestDB].[dbo].tb_score 
commit TRANSACTION

此时

SELECT *  FROM [TestDB].[dbo].tb_score语句被允许“脏读”

该查询未等事务A提交，就已经读出，并且读书的值为A以修改但未提交的值。

例如id=3的score=100，运行A事务的时候，score=101了，此时运行语句B，则立刻返回出id=3的score=101，而不管A是否真的已经提交或者rollback。

还有一点要注意，当你设置了READ uncommitted，那么接下来的sql语句都会是 READ uncommitted。msdn上：一次只能设置一个隔离级别选项，而且设置的选项将一直对那个连接始终有效，直到显式更改该选项为止。事务中执行的所有读取操作都会在指定的隔离级别的规则下运行，除非语句的 FROM 子句中的表提示为表指定了其他锁定行为或版本控制行为。所以在查询分析器中做实验的时候，要注意，一旦设置了READ uncommitted，接下来在当前窗口中的语句都是如此。

3

-----事务A------- 
begin tran 
select *from  [TestDB].[dbo].tb_score with(tablockx) where id=3 
   waitfor delay '00:00:10'   --延迟10秒读取 
commit TRANSACTION


此事务对表加了表级别的排它锁。因此在此期间，

SET TRANSACTION ISOLATION LEVEL 
READ uncommitted 
begin tran 
SELECT *  FROM [TestDB].[dbo].tb_score where id=1 
commit TRANSACTION

更多内容，可以看

http://msdn.microsoft.com/zh-cn/library/ms187373.aspx

http://msdn.microsoft.com/zh-cn/library/ms173763.aspx    

4

此处有些疑问：

两个事务   

-----事务A-------
 begin tran 
 select *from  [TestDB].[dbo].tb_score with(updlock,rowlock) where id=3    waitfor delay '00:00:10'   --延迟10秒读取 
 update  [TestDB].[dbo].tb_score set score=score+1  where id=3 commit TRANSACTION

-----事务B------ 
SET TRANSACTION ISOLATION LEVEL READ committed 
begin tran 
select *from  [TestDB].[dbo].tb_score with(updlock,rowlock) where
id=3
commit TRANSACTION

我的理解是，事务A运行的时候，对id=3的加了行锁，还有更新锁，更新锁的话一定要等到事务运行完才能再被获取。  
因此事务A运行的时候，事务B也马上运行，但是事务B也要对改行获取更新锁，因此被阻塞在此，所以最后运行的结果是A运行完了B在运行。以上一切正常

但是把事务B改成  

-----事务B------- 

SET TRANSACTION ISOLATION LEVEL READ committed 
begin tran 
select *from  [TestDB].[dbo].tb_score with(updlock,rowlock) where id=1
commit TRANSACTION

事务B对id=1的行加锁。  
那么我的理解是，既然事务A加锁的对象是id=3的行，那么和事务B根本不会有什么冲突。但是事实上，运行事务A后马上运行B，发现事务B也会被阻塞。并且事务A还会发出异常错误：说是检测到死锁。    
Transaction (Process ID 52) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

本人愚钝，百思不解，求专家指教。