SQL7中LOCK的理解(2)

　　下面介绍的是锁的并发问题和解决方法
　　在实际情况中，通常会因为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。
　　索引在锁中的应用。
　　大家都知道索引可以提高查询速度，其实索引还有一个很重要的功能就是提高并发。
　　例。当user1 run update tab1 set col1=xxx时，user2对tab1 run select * from tab1将会等待，直到user1执行完。但如果user2执行select * from tab1 where col1<>xxx也就是user2要查询的行并不是user1改写的行，结果如何呢？同样，user2也要等到user1执行完.这样就没有什么并发可言。如果我们在col1上建立index，就可以让user2无须等待，立即执行。更常用的是父表和子表的情况，通常为了保证引用完整性，SQL在修改数据时，都会将依赖表加锁，但如果有index，情况就好的多。

【责编:admin】

--------------------next---------------------