SqlServer事务中的可重复读和序列化隔离界别
http://www.cnblogs.com/OpenCoder/archive/2010/03/23/1692666.html 有表t_lock:
ID是主键,表中有5行数据,1~2,4~6 ? 可重复读: SET ? TRANSACTION ? ISOLATION ? LEVEL ? REPEATABLE ? READ ? begin ? tran select ? * ? from ?t_lock? where ?id? between ? 1 ? and ? 6 执行这个查询后,会在表ID为1,2,4,5,6的行上加上共享锁(s) 执行插入语句 insert ? into ?t_lock? values ( 3 , ' 3 ' )执行成功,原因是插入的是ID为3的数据行并加上排他锁(x),插入语句不会去1,2,4,5,6行申请排它锁,否则就发生阻塞了 序列化: SERIALIZABLE6 ? 根据序列化级别的定义执行查询后会在ID为1~6的范围上RangeS-S范围共享锁,虽然ID为3的行在数据库并不存在,但是由于这里在ID为1~6加上的是范围锁,所以实际上ID为3的行也被加上了RangeS-S锁,一定要记住范围锁是连续的范围,并不因为数据库里数据不存在就不加锁,比如你可以同样执行插入ID为3的sql语句: 结果发生了阻塞,原因就是ID为1~6的行(不管是否存在)都被加上了范围为共享锁,在这个范围除了查询什么也做不了,而上面的插入语句要对ID为3的数据行申请排它锁,肯定会被阻塞.? 序列化的小陷阱: 按道理来说执行了以下sql: 然后插入ID大于6和ID小于1的数据行应该不会被阻塞,因为插入数据的ID位于1~6的范围之外了,可是你可以试着执行以下插入语句: 9 ,0); line-height:1.5!important">9 ' )values (-1 ,0); line-height:1.5!important">'-1 无论是插入ID为-1的行还是ID为9的行都被阻塞,这是为什么?明明插入数据的ID在范围之外啊? 让我们更改数据库中的数据,再来看看两种情况就明白了 首先如果在事务中使用序列化查询后,数据库里的数据是这样:
执行insert into t_lock values(9,'9')不会阻塞 如果在事务中使用序列化查询后,数据库里的数据是这样:
执行insert? into t_lock values(-1,'-1')不会阻塞
看出点眉目来了吗?
(编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |