怎樣解決MySQL數據庫在RR隔離級別下容易產(chǎn)生幻讀

這篇文章將為大家詳細講解有關(guān)怎樣解決數據庫在RR隔離級別下容易產(chǎn)生幻讀的問(wèn)題，文章內容質(zhì)量較高，因此小編分享給大家做個(gè)參考，希望大家閱讀完這篇文章后對相關(guān)知識有一定的了解。

PartⅠ 問(wèn)題回顧

幻讀的定義：幻讀是指某個(gè)事務(wù)讀取某個(gè)范圍內的記錄時(shí)，另外一個(gè)事務(wù)又在該范圍內插入了新的記錄，當之前事務(wù)再次讀取該范圍內的記錄時(shí)就會(huì )產(chǎn)生幻行。

舉一個(gè)例子，user表中id是主鍵索引，T1是主事務(wù)：

T2是干擾事務(wù)：

Step1：T1開(kāi)始，并檢查user表中是否有id=1的記錄。

Step2：T2開(kāi)始，插入id為1的記錄且成功執行。

Step3：T1查到?jīng)]有id=1的記錄就開(kāi)始插入id=1的記錄，但是失敗了（主鍵沖突）。

Step4：T1不能接受現實(shí)又查了一遍是否存在id=1的記錄，發(fā)現的確沒(méi)有，徹底崩潰...

從第四步我們可以看出，在主事務(wù)執行commit之前，不管再查多少次，都無(wú)法獲取到id=1的這條記錄，因為此時(shí)它已經(jīng)產(chǎn)生幻讀了。

Part Ⅱ 解決方案

要解決幻讀的問(wèn)題有兩種方案，一種是采用SERIALIZABLE 數據隔離級別，但是這種方案會(huì )強制把所有事務(wù)排序，來(lái)達到事務(wù)之間不互相沖突產(chǎn)生幻讀的問(wèn)題，當事務(wù)并發(fā)高的時(shí)候，很容易產(chǎn)生大量超時(shí)和鎖競爭的情況，所以一般不太建議采用這種方案。另一種方案是采用在RR數據隔離級別下，手動(dòng)給select操作加上x(chóng)鎖（排它鎖）或者s鎖（共享鎖），下面就具體介紹一下x鎖和s鎖。

1. 什么是共享鎖和排它鎖

共享鎖（SELECT ... LOCK IN SHARE MODE）即一個(gè)事務(wù)獲取一條記錄共享鎖的同時(shí)，其他事務(wù)也可以獲得這條記錄的共享鎖，但是如果同時(shí)有多個(gè)事務(wù)獲得這條記錄的共享鎖，誰(shuí)也無(wú)法修改這條記錄，直到都釋放掉共享鎖，只剩下一個(gè)事務(wù)擁有這條記錄的鎖為止。

排它鎖（SELECT ... FOR UPDATE）即一個(gè)事務(wù)獲得了一條記錄的排它鎖的同時(shí)，其他事務(wù)就不能獲得這條記錄的共享鎖和排它鎖，也無(wú)法修改這條記錄，直到這個(gè)事務(wù)釋放掉鎖為止。

2. 相同點(diǎn)和不同點(diǎn)

相同點(diǎn)：一個(gè)事務(wù)在獲得一條記錄的共享鎖或者排它鎖的同時(shí)，其他事務(wù)都不能修改這條記錄，直到這個(gè)事務(wù)釋放掉鎖為止。

不同點(diǎn)：排它鎖比共享鎖多阻塞了其他事務(wù)對相同記錄的共享鎖，但是不影響快照讀。

3. 舉例說(shuō)明

共享鎖：

排它鎖：

Part Ⅲ  

那共享鎖和排它鎖是否能互相代替呢，這要看具體的場(chǎng)景，像上面兩個(gè)例子就不行，第一個(gè)例子如果用了排它鎖就會(huì )造成一個(gè)用戶(hù)在操作工會(huì )的時(shí)候，其他用戶(hù)就不能獲取這條記錄共享鎖的情況。

第二個(gè)例子如果使用共享鎖的話(huà)，其他事務(wù)都能獲得goods表這條記錄的共享鎖，會(huì )導致誰(shuí)也更新不了剩余數量這個(gè)值的情況。所以共享鎖和排它鎖都有各自的作用，不能互相替代。