事務 - 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。