ά

介绍了数据库方面的基础知识

作者：adam.zhu
email: [e-mail]
日期：7/18/2001 9:18:34 PM
主题：sql7中的lock的理解3 
发信人: cert_studio(certstudio)
整理人: tidycc(2001-04-21 11:07:54), 站内信件  
续上。 

在实际情况中，通常会因为lock发生四中情况。 
下面用个定座系统举例：所有的语句都工作在默认隔离级别下 
1 丢失的更新 
user1 run        
begin tran 
select 空座位 得到1，2，3 
update 1 定座位1 
commit 

如果user2在user1 update之前运行同样的程序，都会得到空座位是1,2,3的信息 

，当然user2也可以定座位1。结果就是user2的定座是最终有效的，user1的定座 

被覆盖。为了避免这种情况，看看用隔离级别能不能解决。 
这四种隔离级别最多在表上施加S，由于S是兼容的，因此user2照样能得到空座位 

是1,2,3的信息，丢失的更新也照样会发生。SQL提供了表级锁定选项TABLOCKX， 
能避免这种情况的发生，但丧失了并发。 


2 脏读 
user1 run 
begin tran 
update row A 
commit 

如果user2能在user1 update的同时读出表中的数据(包含 row A) 那么就产生了 

脏读，因为user1可能commit也可能rollback，update并没有被确认。默认情况下 

是不会产生脏读的，因为update将产生行的X，表的IX，而表IX和S是不兼容的。 

那么在什么情况下我们需要脏读呢，如果我们不需要确切的数据，我们需要的是 

一个大概的趋势，个别数据的不确定没有关系，想想一个股票系统，同一时刻的 

改写会很多，也就是表上会有许多IX锁，如果我们需要查询表获得大致情况，那 

么只有等改写结束，为了提高并发，此时我们需要脏读。解决方法就是在user2的 

会话环境中设置事务隔离级别为read uncommitted 


3 不可重复读 
user1 run 
begin tran 
select tab1 where 
... 
... 
select tab1 where 
commit 

当user1在交易中执行两次select，所得到的结果不一样，这便是不可重复读。 
发生的原因是user2在user1第二次select之前对tab1做了修改。select语句虽然 

对表有读锁，但在默认情况下，读锁在select语句执行完就被释放，而不是保持 

到交易结束。为了避免不可重复读的发生，只要select产生的锁保持到交易结束 

就可以了，将user1的会话环境中设置事务隔离级别为repeatable read 


4 幻影  
user1 run 
begin tran 
select tab1 where  
... 
... 
select tab1 where 
commit 
虽然将user1的会话环境中设置事务隔离级别为repeatable read，但当user1在交 

易中执行两次select，所得到的结果还会不一样，这便是幻影。因为user1仅仅将 

select出来的行加了S锁，但user2可以insert满足where条件的新行，使得两次 

select的结果不一样，解决方法是将user1的会话环境中设置事务隔离级别为 

serializable,或者在表级锁定选项中选holdlock 


锁定超时： 
前面说过，当某个语句因为锁而不能立即执行时，会等待，直到锁被释放。但如 

果持有锁的语句执行时间过长(未优化)。那么就会等待过长，影响响应，因此， 

我们通过lock_timeout来将等待过长的语句rollback。需要注意的是，当数据量 

增加时，可能发生不希望的lock_timeout。原因是SQL需要更多的时间来处理数据 

，为此我们也需要适当的增加lock_timeout。