共計 1215 個字符，預計需要花費 4 分鐘才能閱讀完成。

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

PartⅠ 問題回顧

幻讀的定義：幻讀是指某個事務讀取某個范圍內的記錄時，另外一個事務又在該范圍內插入了新的記錄，當之前事務再次讀取該范圍內的記錄時就會產生幻行。

舉一個例子，user 表中 id 是主鍵索引，T1 是主事務：

T2 是干擾事務：

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

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

Step3：T1 查到沒有 id= 1 的記錄就開始插入 id= 1 的記錄，但是失敗了（主鍵沖突）。

Step4：T1 不能接受現實又查了一遍是否存在 id= 1 的記錄，發現的確沒有，徹底崩潰 …

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

Part Ⅱ 解決方案

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

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

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

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

2. 相同點和不同點

相同點：一個事務在獲得一條記錄的共享鎖或者排它鎖的同時，其他事務都不能修改這條記錄，直到這個事務釋放掉鎖為止。

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

3. 舉例說明

共享鎖：

排它鎖：

Part Ⅲ 

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

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

關于怎樣解決 MySQL 數據庫在 RR 隔離級別下容易產生幻讀的問題就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。