sql中select * from t where c=5 for update排它锁的示例分析

小编给大家分享一下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排它锁的示例分析"这篇文章的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注行业资讯频道！