事務(wù) - mysql共享鎖lock in share mode的實(shí)際使用場景
問題描述
看了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ù)呢?
問題解答
回答1:確實(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。
相關(guān)文章:
1. javascript - 原生canvas中如何獲取到觸摸事件的canvas內(nèi)坐標(biāo)?2. 對(duì)mysql某個(gè)字段監(jiān)控的功能3. html - vue項(xiàng)目中用到了elementUI問題4. mysql優(yōu)化 - mysql EXPLAIN之后怎么看結(jié)果進(jìn)行優(yōu)化 ?5. JavaScript事件6. css3 - css怎么實(shí)現(xiàn)圖片環(huán)繞的效果7. css3 - border-bottom 的長度可否超過盒子的寬度呢?實(shí)現(xiàn)如下圖效果。(我的書下面的線)8. showpassword里的this 是什么意思?代表哪個(gè)元素9. javascript - windows下如何使用babel,遇到了困惑10. mysql scripts提示 /usr/bin/perl: bad interpreter
