发信人: 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。
|
|