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