事务 - 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

これは実際に当てはまります。LOCK IN SHARE MODE は読み取りロック (他のユーザーが書き込みできないようにするだけ)、FOR UPDATE は書き込みロック (他のユーザーが読み取りロックを追加することを許可しません)、 は読み取りロックを書き込みロックにアップグレードします。 Deadlock (ただし、書き込みロックが読み取りロックにダウングレードされる場合は起こりません。MySQL がどのようにロックをダウングレードするのかは実際にはわかりません)。プログラム内で考慮する必要があります (再試行するか諦めるか)。

したがって、ほとんどの場合、SELECT の後に UPDATE アクションがある場合は、通常、LOCK IN SHARE MODE の代わりに FOR UPDATE を使用します。