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

问题描述

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

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

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

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

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

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

问题解答

确实是这样的，LOCK IN SHARE MODE是读锁(只是不让别人写)，FOR UPDATE是写锁(还不让别人加读锁)，读锁升级成写锁是可能产生死锁的(但写锁降级成读锁则不会，我还真不知道MySQL如何对锁降级)，所以程序中需要考虑超时的问题(或者重试或者放弃)。

所以大部分情况下都如果SELECT后接下来会有UPDATE动作的话，一般会用FOR UPDATE而不是LOCK IN SHARE MODE。