Sql Server 锁

theoforce

　　1.排它锁
在一个Sql连接中这样写：
begin tran
--select * from  a with(UPDLOCK)
update a set [name]='wq' where [id]=2   --这里的set的值不能不变（即不能本来name='wq'又set name='wq'），否则Sql Server会优化
　　成不加锁
waitfor delay '00:00:08'
commit tran
在另外一个sql连接中这样写：
select * from a
发现第二个连接里的sql语句必须等到第一个连接里的事务完成才执行完成，这是因为第一个连接里的update语句自动加了独占锁
　　
　　
　　2.Sql Server 默认锁
即INSERT、 UPDATE 或DELETE 命令时，SQL Server 会自动使用独占锁。
Select语句：1.当事务的隔离级别为 READ  committed，READ  uncommitted 时为不加锁，既unlock
     2.当事务的隔离级别为 REPEATABLE READ，SERIALIZABLE时，为共享锁，既HoldLock
　　
　　
　　3.事务隔离级别：
1.REPEATABLE READ
在第一个Sql连接的一个事务中这样设置以后，那么在第二个Sql连接里，不能对第一个连接里事务操作的表进行update，delete操作，但是能进行
　　insert操作，且新插入的行包括在第一个连接的当前事务的后续读取中
2.SERIALIZABLE
在数据集上放置一个范围锁，以防止其他用户在事务完成之前更新数据集或将行插入数据集内。这是四个隔离级别中限制最大的级别。因为并发级别
　　较低，所以应只在必要时才使用该选项。该选项的作用与在事务内所有 SELECT 语句中的所有表上设置 HOLDLOCK 相同。即在第一个Sql连接的一个事
　　务中这样设置以后，那么在第二个Sql连接里，不能对第一个连接里事务操作的表进行update，delete，insert操作
　　
　　
4.关于更新锁
在一个Sql连接中这样写：
begin tran
begin tran
select * from a with(updlock) where [id] in (2,3,4)
  waitfor delay '00:00:04'
commit tran
在另外一个sql连接中这样写：
select * from a with(updlock) where [id] =4
发现第二个连接里的sql语句必须等到第一个连接里的事务完成才执行完成，这是因为第二个连接的更新锁认为第一个连接里的更新锁可能会进行修改
　　转换为排它锁，所以要等第一个连接的事务执行完成才执行。如果第二个连接里的sql语句这样写：select * from a with(holdlock) where [id]
　　=4,则不不用等第一个连接事务执行完毕才执行。