sql中select*fromtwherec=5forupdate排它锁的示例分析
小编给大家分享一下sql中select * from t where c=5 for update排它锁的示例分析,相信大部分人都还不怎么了解,因此分享这篇文章给大家参考一下,希望大家阅读完这篇文章后大有收获,下面让我们一起去了解一下吧!
创新互联公司网站建设公司是一家服务多年做网站建设策划设计制作的公司,为广大用户提供了成都网站制作、成都网站建设,成都网站设计,一元广告,成都做网站选创新互联公司,贴合企业需求,高性价比,满足客户不同层次的需求一站式服务欢迎致电。
RC隔离级别下,
update产生的X锁在不释放的情况下,
DELETE语句无法执行,
但是UPDATE语句能更新不符合之前X锁的记录。
不符合条件的会及时释放行锁,不必等事务结束时释放;
RC没有间隙锁的概念
对非索引字段更新,有个锁全表记录的过程,
而直接用索引列更新,只会锁索引查找值和行。
RR隔离级别下,为保证binlog记录顺序,
非索引更新会锁住全表记录,
且事务结束前不会对不符合条件记录有逐步释放的过程。
DELETE和UPDATE语句都不能执行
版本5.7.13
rc模式下:
session 1:
begin;
select * from t where c=5 for update;
session 2:
delete from t where c=10 --等待
session 3:
insert into t values(100001,8) --成功
session 4 : update t set c=100 where id=10 -- 成功
session 1:
commit
session 2:事务执行成功
rr模式下:
begin;
select * from t where c=5 for update;
session 2:
delete from t where c=10 --等待
session 3:
insert into t values(100001,8) --等待
session 4 : update t set c=100 where id=10 --等待
session 1:
commit
session 2:事务执行成功
session 3:事务执行成功
从上面这两个简单的例子,可以大概看出上锁的流程.
不管是rr模式还是rc模式,这条语句都会先在server层对表加上MDL S锁,然后进入到引擎层。
rc模式下,由于数据量不大只有10W。通过实验可以证明session 1上来就把该表的所有行都锁住了。
导致其他事务要对该表的所有现有记录做更新,是阻塞状态。为什么insert又能成功?
说明rc模式下for update语句没有上gap锁,所以不阻塞insert对范围加插入意向锁,所以更新成功。
session 1commit后,session 2执行成功。表明所有行的x锁是在事务提交完成以后才释放。
rr模式下,session 1和session 2与rc模式下都一样,说明rr模式下也对所有行上了X锁。
唯一的区别是insert也等待了,是因为rr模式下对没有索引的更新,聚簇索引上的所有记录,都被加上了X锁。其次,聚簇索引每条记录间的间隙(GAP),也同时被加上了GAP锁。由于gap锁阻塞了insert要加的插入意向锁,导致insert也处于等待状态。只有当session 1 commit完成以后。session 1上的所有锁才会释放,S2,S3执行成功
由于例子中的数据量还比较小,如果数据量达到千万级别,就比较直观的能看出,上锁是逐行上锁的一个过程.扫描一条上一条,直到所有行扫描完,rc模式下对所有行上x锁。rr模式下不仅对所有行上X锁,还对所有区间上gap锁.直到事务提交或者回滚完成后,上的锁才会被释放。
以上是“sql中select * from t where c=5 for update排它锁的示例分析”这篇文章的所有内容,感谢各位的阅读!相信大家都有了一定的了解,希望分享的内容对大家有所帮助,如果还想学习更多知识,欢迎关注创新互联行业资讯频道!
网站栏目:sql中select*fromtwherec=5forupdate排它锁的示例分析
当前URL:http://hbruida.cn/article/ggoidp.html