事务 - mysql共享锁lock in share mode的实际使用场景

Question

看了MySQL的官方文档: 关于锁定对象的部分

分两种锁
共享锁: SELECT ... LOCK IN SHARE MODE
排它锁: SELECT ... FOR UPDATE

其中排他锁这个场景大家都知道, 就是多个session的事务要对同一个表的一/多条数据进行更新操作的时候, 要先锁定再更新来消除并发造成的数据不一致

而共享锁的使用场景说的有主-从表的这种情况, 比如想在从表insert一条记录, 需要先将主表相关的数据加S锁锁定, 然后再insert从表, 来实现主从表数据一致性, 即有可能其他session会再此时delete主表的这条数据而造成只有从表有数据而主表无数据的数据不一致结果

但是显示加S锁容易造成deadLock, 即session1在数据加S锁, 然后session2在相同数据也加S锁, 然后同时update, 必然会导致其中一个session的事务监测到deadlock,而终止事务

本来他的使用场景是主-从表的情况, 但是实际场景可能错综复杂, 这两种场景都是涉及, 那么手动加共享锁的是否还有必要呢???? 是否说明实际中不会使用这项技术呢?

Answer 1

It is indeed like this, LOCK IN SHARE MODE是读锁(只是不让别人写)，FOR UPDATEIt is a write lock (it does not allow others to add a read lock), Upgrading the read lock to a write lock may cause a deadlock(But downgrading the write lock to a read lock will not, I really don’t Know how MySQL degrades locks), so the timeout issue needs to be considered in the program (either retry or give up).

So in most cases, if there is an UPDATE action after SELECT, you will generally use FOR UPDATE instead of LOCK IN SHARE MODE.