看了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。