目錄
- 一、隔離級別
- READ UNCOMMITED(讀未提交)
- READ COMMITED(提交讀/不可重復讀)
- REPEATED READ(可重復讀)
- SERIALIZABLE (可串行化)
- 二、MVCC
Mysql是我們日常生產與學習中最常接觸到的數據庫之一,今天講一講在Mysql(或者說其他類似的數據庫)中存在的隔離級別以及用來提高效率的多版本并發控制(MVCC)。
一、隔離級別
首先我們需要提到一個概念:事務。什么是事務?事務就是完成一個基礎操作的一系列操作語句的一個集合。例如我要將200元從賬戶A轉移到賬戶B,那么我可能會進行一下的操作:
a.驗證賬戶A中的余額是否大于200元。
b.將賬戶A中的余額減200元。
c.將賬戶B中的余額加200元。
我們就將上面的abc三個操作成為一個事務。
這時,我們會注意到我們所說的一個事務有可能是由多條語句組合而成的,而事務又存在原子性,即事務的執行過程中是不能被打斷的,這就帶來一個問題,如果在這三步執行過程中有另外的語句插入進來執行,是否會對結果產生影響,因為此時破壞了事務的原子性。而這種插入的情況在并發的環境下是十分常見的。因此,我們(或者說是數據庫引擎)就需要在一個事務的執行過程中對它進行“保護”,即保證外界的其他事務的語句不能隨意的插進正在執行的事務語句之中,來保證事務的正常執行。這時候我們很容易的會想到“加鎖”這個方法。這其實是一種很籠統的說法,因為加鎖雖然能夠保證事務的正常執行,但是卻會帶來較大的額外開銷,因此合適的時候選擇合適的加鎖方式對查找效率的影響就非常大。而“鎖”得嚴不嚴,就區分除了集中不同的隔離級別。
READ UNCOMMITED(讀未提交)
這種隔離界別下,讀取數據的時候不受任何影響。即你甚至可以讀取一個正在被其他事務修改的數據,想讀就讀,想改就改。這當然開銷很小,但是會帶來許多的問題,比如“臟讀”。即讀取到了正在修改但是卻還沒有提交的數據,這就會造成數據讀取的錯誤。從性能上來說,READ UNCOMMITED不會比其他級別好太多,但是卻帶來了非常多的麻煩的問題,因此在實際中很少使用這個個立即被。
READ COMMITED(提交讀/不可重復讀)
這個級別在READ UNCOMMITED的基礎上添加了一些規定,是一些數據庫的默認隔離級別。它與READ UNCOMMITED的區別在于,它規定讀取的時候讀到的數據只能是提交后的數據。舉個例子,數據a在上一次提交之后的值是1,這時候有一個線程進來對a進行修改,將a修改為2,但是此時并未提交事務(COMMIT),在這種情況下,READ UNCOMMITED級別下讀取到的a的值就是當前的2,但是READ COMMITED級別下讀取到的還是上一次提交之后的值,即a為1,必須到修改線程將a的值變為2這個事務提交之后讀取到的a的值才是2。這個級別所帶來的問題就是不可重復讀。即上一個時間讀取到的a的值是1,但是隨著修改線程對事務的提交,a的值變為了2,這時候讀到的值就是2了,即執行兩次相同的讀取操作得到的值卻不一樣。
不可重復讀同臟讀的區別在于,臟讀是一個事務讀取了另一未完成的事務執行過程中的數據,而不可重復讀是一個事務執行過程中,另一事務提交并修改了當前事務正在讀取的數據。
REPEATED READ(可重復讀)
REPEATED READ在READ COMMITED的基礎上又添加了一些約束性的規則,它也是MySQL數據庫的默認隔離級別。簡單來說就是在一個事務的執行期間禁止其他事務對相應的數據進行修改,這就徹底使得一個事務的執行過程中所查詢到的數據一定是一致的,即解決了臟讀和不可重復讀的問題,但是卻帶來了新的問題,即“幻讀”。
“幻讀”指的是在一個事務執行過程中雖然禁止了對相應數據的修改,但是其他的事務依然可以插入數據,這時候第一個事務就會發現會“莫名其妙”多出來一些數據,像是出現了幻覺似的。幻讀和不可重復讀都是讀取了另一條已經提交的事務(這點同臟讀不同),所不同的是不可重復讀查詢的都是同一個數據項,而幻讀針對的是一批數據整體(比如數據的個數)。
SERIALIZABLE (可串行化)
這是最嚴格的一個隔離級別。它通過強制事務串行執行,避免了幻讀的問題。但是這種隔離級別的開銷極大,一般也不常使用。
各種隔離級別與可能的問題關系如下:
隔離級別 |
臟讀 |
不可重復讀 |
幻讀 |
加鎖 |
READ UNCOMMITED |
YES |
YES |
YES |
NO |
READ COMMITED |
NO |
YES |
YES |
NO |
REPEATED READ |
NO |
NO |
YES |
NO |
SERIALIZABLE |
NO |
NO |
NO |
YES |
二、MVCC
試想一下,如果每次SQL操作為了保證數據的一致性與準確性,都需要加一個行級鎖的話,非常可靠,但是帶來的系統開銷與查找效率的下降也是非常明顯的,因此MVCC就是為了解決這種矛盾而產生的。
首先MVCC會在表中的每一行記錄后面保存兩個隱藏的列,一個保存行的創建時間,一個保存行的過期(刪除)時間。這個時間值并不是真的時間,而是一個系統版本號。事務開始的時刻的系統版本號作為事務的版本號,用來和查詢到的每行記錄的版本號進行比較。
- INSERT:為新插入的每一行保存當前的系統版本號作為行版本號。
- DELETE:為刪除的每一行保存當前的系統版本號最為行刪除版本號。
- UPDATE:更新其實應該理解為插入一條新的數據,并刪除原來數據的過程,即為新插入的數據保存當前的系統版本號作為行版本號,并為刪除的數據保存當前的系統版本號作為刪除版本號。
- SELECT:只查詢滿足下列條件的行:
a.行版本號小于等于事務版本號
b.刪除版本號未定義或者大于事務版本號
保存了這兩個版本號之后絕大多數的操作都可以在不加鎖的情況下進行正確的操作,保證了性能和效率。
值得注意的是MVCC只在READ COMMITED和REPEATABLE READ兩個隔離級別下工作。
以上就是詳解MySQL 數據庫隔離級別與MVCC的詳細內容,更多關于MySQL 數據庫隔離級別與MVCC的資料請關注腳本之家其它相關文章!
您可能感興趣的文章:- 詳解MySQL事務的隔離級別與MVCC
- Mysql MVCC機制原理詳解
- mysql的MVCC多版本并發控制的實現
- MySQL中的樂觀鎖,悲觀鎖和MVCC全面解析
- 淺析MySQL - MVCC
- mysql多版本并發控制MVCC的實現
- 關于Mysql隔離級別、鎖與MVCC介紹
- 詳解MySQL多版本并發控制機制(MVCC)源碼