站長資訊網本篇文章給大家帶來了關于MySQL事務與MVCC如何實現的隔離級別的相關問題，希望對大家有幫助。
數據庫事務介紹
事務的四大特性（ACID）
-
原子性(atomicity)： 事務的最小工作單元，要么全成功，要么全失敗。
-
一致性(consistency)： 事務開始和結束后，數據庫的完整性不會被破壞。
-
隔離性(isolation)： 不同事務之間互不影響，四種隔離級別為RU（讀未提交）、RC（讀已提交）、RR（可重復讀）、SERIALIZABLE （串行化）。
-
持久性(durability)： 事務提交后，對數據的修改是永久性的，即使系統故障也不會丟失。
事務的隔離級別
讀未提交（Read UnCommitted/RU）
又稱為臟讀，一個事務可以讀取到另一個事務未提交的數據。這種隔離級別歲最不安全的一種，因為未提交的事務是存在回滾的情況。
讀已提交（Read Committed/RC）
又稱為不可重復讀，一個事務因為讀取到另一個事務已提交的修改數據，導致在當前事務的不同時間讀取同一條數據獲取的結果不一致。
舉個例子，在下面的例子中就會發現SessionA在一個事務期間兩次查詢的數據不一樣。原因就是在于當前隔離級別為 RC，SessionA的事務可以讀取到SessionB提交的最新數據。
| 發生時間 | SessionA | SessionB |
|---|---|---|
| 1 | begin; | |
| 2 | select * from user where id=1;(張三) | |
| 3 | update user set name='李四' where id=1;(默認隱式提交事務) | |
| 4 | select * from user where id=1;(李四) | |
| 5 | update user set name='王二' where id=1;(默認隱式提交事務) | |
| 6 | select * from user where id=1;(王二) |
可重復讀（Repeatable Read/RR）
又稱為幻讀，一個事物讀可以讀取到其他事務提交的數據，但是在RR隔離級別下，當前讀取此條數據只可讀取一次，在當前事務中，不論讀取多少次，數據任然是第一次讀取的值，不會因為在第一次讀取之后，其他事務再修改提交此數據而產生改變。因此也成為幻讀，因為讀出來的數據并不一定就是最新的數據。
舉個例子：在SessionA中第一次讀取數據時，后續其他事務修改提交數據，不會再影響到SessionA讀取的數據值。此為可重復讀。
| 發生時間 | SessionA | SessionB |
|---|---|---|
| 1 | begin; | |
| 2 | select * from user where id=1;(張三) | |
| 3 | update user set name='李四' where id=1; (默認隱式提交事務) | |
| 4 | select * from user where id=1;(張三) | |
| 5 | update user set name='王二' where id=1;(默認隱式提交事務) | |
| 6 | select * from user where id=1;(張三) |
串行化（Serializable）
所有的數據庫的讀或者寫操作都為串行執行，當前隔離級別下只支持單個請求同時執行，所有的操作都需要隊列執行。所以種隔離級別下所有的數據是最穩定的，但是性能也是最差的。數據庫的鎖實現就是這種隔離級別的更小粒度版本。
| 發生時間 | SessionA | SessionB |
|---|---|---|
| 1 | begin; | |
| 2 | begin; | |
| 3 | update user set name='李四' where id=1; | |
| 4 | select * from user where id=1;(等待、wait) | |
| 5 | commit； | |
| 6 | select * from user where id=1;(李四) |
事務和MVCC原理
不同事務同時操作同一條數據產生的問題
示例：
| 發生時間 | SessionA | SessionB |
|---|---|---|
| 1 | begin; | |
| 2 | begin; | |
| 3 | 查詢余額 = 1000元 | |
| 4 | 查詢余額 = 1000元 | |
| 5 | 存入金額 100元，修改余額為 1100元 | |
| 6 | 取出現金100元，此時修改余額為900元 | |
| 8 | 提交事務（余額=1100） | |
| 9 | 提交事務（余額=900） |
| 發生時間 | SessionA | SessionB |
|---|---|---|
| 1 | begin; | |
| 2 | begin; | |
| 3 | 查詢余額 = 1000元 | |
| 4 | 查詢余額 = 1000元 | |
| 5 | 存入金額 100元，修改余額為 1100元 | |
| 6 | 取出現金100元，此時修改余額為900元 | |
| 8 | 提交事務（余額=1100） | |
| 9 | 撤銷事務（余額恢復為1000元） |
上面的兩種情況就是對于一條數據，多個事務同時操作可能會產生的問題，會出現某個事務的操作被覆蓋而導致數據丟失。
LBCC 解決數據丟失
LBCC，基于鎖的并發控制，Lock Based Concurrency Control。
使用鎖的機制，在當前事務需要對數據修改時，將當前事務加上鎖，同一個時間只允許一條事務修改當前數據，其他事務必須等待鎖釋放之后才可以操作。
MVCC 解決數據丟失
MVCC，多版本的并發控制，Multi-Version Concurrency Control。
使用版本來控制并發情況下的數據問題，在B事務開始修改賬戶且事務未提交時，當A事務需要讀取賬戶余額時，此時會讀取到B事務修改操作之前的賬戶余額的副本數據，但是如果A事務需要修改賬戶余額數據就必須要等待B事務提交事務。
MVCC使得數據庫讀不會對數據加鎖，普通的SELECT請求不會加鎖，提高了數據庫的并發處理能力。借助MVCC，數據庫可以實現READ COMMITTED，REPEATABLE READ等隔離級別，用戶可以查看當前數據的前一個或者前幾個歷史版本，保證了ACID中的I特性（隔離性)。
InnoDB的MVCC實現邏輯
InnoDB存儲引擎保存的MVCC的數據
InnoDB的MVCC是通過在每行記錄后面保存兩個隱藏的列來實現的。一個保存了行的事務ID（DB_TRX_ID），一個保存了行的回滾指針（DB_ROLL_PT）。每開始一個新的事務，都會自動遞增產 生一個新的事務id。事務開始時刻的會把事務id放到當前事務影響的行事務id中，當查詢時需要用當前事務id和每行記錄的事務id進行比較。
下面看一下在REPEATABLE READ隔離級別下，MVCC具體是如何操作的。
SELECT
InnoDB 會根據以下兩個條件檢查每行記錄：
-
InnoDB只查找版本早于當前事務版本的數據行（也就是，行的事務編號小于或等于當前事務的事務編號），這樣可以確保事務讀取的行，要么是在事務開始前已經存在的，要么是事務自身插入或者修改過的。
-
刪除的行要事務ID判斷，讀取到事務開始之前狀態的版本，只有符合上述兩個條件的記錄，才能返回作為查詢結果。
INSERT
InnoDB為新插入的每一行保存當前事務編號作為行版本號。
DELETE
InnoDB為刪除的每一行保存當前事務編號作為行刪除標識。
UPDATE
InnoDB為插入一行新記錄，保存當前事務編號作為行版本號，同時保存當前事務編號到原來的行作為行刪除標識。
保存這兩個額外事務編號，使大多數讀操作都可以不用加鎖。這樣設計使得讀數據操作很簡單，性能很好，并且也能保證只會讀取到符合標準的行。不足之處是每行記錄都需要額外的存儲空間，需要做
