select * from t where c=5 for update 排它锁

• RC隔离级别下，
  • 对非索引字段更新，有个锁全表记录的过程，
    • 不符合条件的会及时释放行锁，不必等事务结束时释放；
  • 而直接用索引列更新，只会锁索引查找值和行。
    • update产生的X锁在不释放的情况下，
      • DELETE语句无法执行，
      • 但是UPDATE语句能更新不符合之前X锁的记录。
• 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锁.直到事务提交或者回滚完成后,上的锁才会被释放。