事务 - 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는 쓰기 잠금입니다(그러나 다른 사람이 읽기 잠금을 추가하는 것을 허용하지 않음)), 읽기 잠금을 쓰기 잠금으로 업그레이드하면 교착 상태가 발생할 수 있습니다(그러나 쓰기 잠금을 읽기 잠금으로 다운그레이드하면 그렇지 않습니다. 실제로 방법을 모르겠습니다. MySQL은 잠금을 다운그레이드하므로 프로그램에서 시간 초과 문제를 고려해야 합니다(재시도 또는 포기).

따라서 대부분의 경우 SELECT 이후에 UPDATE 작업이 있는 경우 일반적으로 LOCK IN SHARE MODE 대신 FOR UPDATE를 사용합니다.