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 col1xxx也就是user2要查询的行并不是user1改写的行，结果如何呢？同样，user2也要等到user1执行完.这样就没有什么并发可言。如果我们在col1上建立index，就可以让user2无须等待，立即执行。更常用的是父表和子表的情况，通常为了保证引用完整性，SQL在修改数据时，都会将依赖表加锁，但如果有index，情况就好的多。 <