問題描述

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

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

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

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

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

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

問題解答

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

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