mysql併發控制

小樓昨夜又西風發表於2019-03-06

在這裡插入圖片描述
在這裡插入圖片描述解釋: Read uncommitted(未提交讀),就是說一個執行緒修改了某一個資料之後,還沒有提交之前,就被其他執行緒讀到修改後的資料,這樣一來肯定會產生問題
Read committed(提交讀),(大多數資料庫系統的預設隔離級別)就是說A執行緒修改了結果以後,必須提交之後才能被其他執行緒讀到新結果,在他還沒有提交之前,資料還是舊的資料。但是這樣有一個紕漏,就是A執行緒在訪問修改該資料的時候,其他執行緒也有可能隨時讀取到資料,這樣的話,其他執行緒可能拿到的是舊資料,一旦A執行緒提交修改以後,其他執行緒那邊的資料立刻重新整理(valotile關鍵字的作用),所以還是可能會出現一些問題
參考連結: https://blog.csdn.net/qq_40241957/article/details/83653379
Repeatable read(可重複讀):在這裡插入圖片描述
Serializable(可序列化):由於它大量的加鎖,所以效能低下,雖然可以避免很多資料讀取問題。

在這裡插入圖片描述
在這裡插入圖片描述
在這裡插入圖片描述
在這裡插入圖片描述
資料庫的隔離級別詳解參考連結:https://blog.csdn.net/qq_40241957/article/details/83653379
解釋:
①為什麼read-uncommitted由於是讀到未提交的,所以不存在版本的問題?
答: 因為讀未提交可以讀到其他事務未提交的更新,每次拿去的都是最新的資料 ,所以版本號永遠都是最新的
②為什麼read-uncommitted隔離級別不能使用mvcc?
答: 因為讀未提交會讀取到別人可能回滾的更新資料,所以資料不對,所以不建議使用mvcc
③為什麼REPEATABLE READ則是讀取事務開始時的行資料版本?
答: 因為可重複度保證了每一行的記錄的一致性(也就是說事務處理的基本單位是“行”),所以當事務開始時,讀取事務開始的行資料版本即可
小疑問: 為什麼只有read-commited讀取的是行資料的最新版本?為什麼因為read-uncommited是讀未提交的,所以不存在版本問題呢?上述圖中最後一個括號裡面的(注:事務A,事務B。。。。。。。)是什麼意思呢?
答: read-commited是通過“鎖行”的方式來防止其他事務干擾

在這裡插入圖片描述
解釋: 什麼是意向鎖概念?
例如,當讀取表裡的頁面時,在請求頁共享鎖(S鎖)之前,事務在表級請求共享意向鎖。這樣可以防止其他事務隨後在表上獲取排他鎖(X鎖),修改整個表格。意向鎖可以提高效能,因為資料庫引擎僅在表級檢查意向鎖,確定事務是否能安全地獲取該表上的鎖,而不需要檢查表中的每行或每頁上的鎖以確定事務是否可以鎖定整個表。(意向鎖是更粗粒度的鎖,相當於在最外層,其他事務訪問資料之前最先檢測到的就是意向鎖
在這裡插入圖片描述
5.死鎖的解決辦法?
產生死鎖後需要由一個事務進行回滾,一般是選擇回滾undo量最小的事務,一般是表鎖引起死鎖,因為其佔用大量鎖資源

相關文章