問題描述

看了MySQL的官方文檔: 關(guān)于鎖定對象的部分

分兩種鎖共享鎖: SELECT ... LOCK IN SHARE MODE排它鎖: SELECT ... FOR UPDATE

其中排他鎖這個場景大家都知道, 就是多個session的事務(wù)要對同一個表的一/多條數(shù)據(jù)進(jìn)行更新操作的時候, 要先鎖定再更新來消除并發(fā)造成的數(shù)據(jù)不一致

而共享鎖的使用場景說的有主-從表的這種情況, 比如想在從表insert一條記錄, 需要先將主表相關(guān)的數(shù)據(jù)加S鎖鎖定, 然后再insert從表, 來實現(xiàn)主從表數(shù)據(jù)一致性, 即有可能其他session會再此時delete主表的這條數(shù)據(jù)而造成只有從表有數(shù)據(jù)而主表無數(shù)據(jù)的數(shù)據(jù)不一致結(jié)果

但是顯示加S鎖容易造成deadLock, 即session1在數(shù)據(jù)加S鎖, 然后session2在相同數(shù)據(jù)也加S鎖, 然后同時update, 必然會導(dǎo)致其中一個session的事務(wù)監(jiān)測到deadlock,而終止事務(wù)

本來他的使用場景是主-從表的情況, 但是實際場景可能錯綜復(fù)雜, 這兩種場景都是涉及, 那么手動加共享鎖的是否還有必要呢???? 是否說明實際中不會使用這項技術(shù)呢?

問題解答

確實是這樣的，LOCK IN SHARE MODE是讀鎖(只是不讓別人寫)，F(xiàn)OR UPDATE是寫鎖(還不讓別人加讀鎖)，讀鎖升級成寫鎖是可能產(chǎn)生死鎖的(但寫鎖降級成讀鎖則不會，我還真不知道MySQL如何對鎖降級)，所以程序中需要考慮超時的問題(或者重試或者放棄)。

所以大部分情況下都如果SELECT后接下來會有UPDATE動作的話，一般會用FOR UPDATE而不是LOCK IN SHARE MODE。