溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章主要講解了“MySQL事務和MVCC怎么實現(xiàn)隔離級別”，文中的講解內(nèi)容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“MySQL事務和MVCC怎么實現(xiàn)隔離級別”吧！
原子性(atomicity)： 事務的最小工作單元，要么全成功，要么全失敗。
一致性(consistency)： 事務開始和結束后，數(shù)據(jù)庫的完整性不會被破壞。
隔離性(isolation)： 不同事務之間互不影響，四種隔離級別為RU（讀未提交）、RC（讀已提交）、RR（可重復讀）、SERIALIZABLE （串行化）。
持久性(durability)： 事務提交后，對數(shù)據(jù)的修改是永久性的，即使系統(tǒng)故障也不會丟失。
讀未提交（Read UnCommitted/RU）
又稱為臟讀，一個事務可以讀取到另一個事務未提交的數(shù)據(jù)。這種隔離級別歲最不安全的一種，因為未提交的事務是存在回滾的情況。
讀已提交（Read Committed/RC）
又稱為不可重復讀，一個事務因為讀取到另一個事務已提交的修改數(shù)據(jù)，導致在當前事務的不同時間讀取同一條數(shù)據(jù)獲取的結果不一致。
舉個例子，在下面的例子中就會發(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;(李四) |
示例：
| 發(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，基于鎖的并發(fā)控制，Lock Based Concurrency Control。
使用鎖的機制，在當前事務需要對數(shù)據(jù)修改時，將當前事務加上鎖，同一個時間只允許一條事務修改當前數(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的數(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)的版本，只有符合上述兩個條件的記錄，才能返回作為查詢結果。
INSERT
InnoDB為新插入的每一行保存當前事務編號作為行版本號。
DELETE
InnoDB為刪除的每一行保存當前事務編號作為行刪除標識。
UPDATE
InnoDB為插入一行新記錄，保存當前事務編號作為行版本號，同時保存當前事務編號到原來的行作為行刪除標識。
保存這兩個額外事務編號，使大多數(shù)讀操作都可以不用加鎖。這樣設計使得讀數(shù)據(jù)操作很簡單，性能很好，并且也能保證只會讀取到符合標準的行。不足之處是每行記錄都需要額外的存儲空間，需要做更多的行檢查工作，以及一些額外的維護工作。
MVCC只在REPEATABLE READ和READ COMMITIED兩個隔離級別下工作。其他兩個隔離級別都和 MVCC不兼容 ，因為READ UNCOMMITIED總是讀取最新的數(shù)據(jù)行，而不是符合當前事務版本的數(shù)據(jù)行。而SERIALIZABLE則會對所有讀取的行都加鎖。
MVCC 在mysql 中的實現(xiàn)依賴的是 undo log 與 read view 。
undo log
根據(jù)行為的不同，undo log分為兩種：insert undo log 和 update undo log
insert undo log：
insert 操作中產(chǎn)生的undo log，因為insert操作記錄只對當前事務本身課件，對于其他事務此記錄不可見，所以 insert undo log 可以在事務提交后直接刪除而不需要進行purge操作。
purge的主要任務是將數(shù)據(jù)庫中已經(jīng) mark del 的數(shù)據(jù)刪除，另外也會批量回收undo pages
數(shù)據(jù)庫 Insert時的數(shù)據(jù)初始狀態(tài)：
update undo log：
update 或 delete 操作中產(chǎn)生的 undo log。因為會對已經(jīng)存在的記錄產(chǎn)生影響，為了提供 MVCC機制，因此update undo log 不能在事務提交時就進行刪除，而是將事務提交時放到入 history list 上，等待 purge 線程進行最后的刪除操作。
數(shù)據(jù)第一次被修改時：
當另一個事務第二次修改當前數(shù)據(jù)：
為了保證事務并發(fā)操作時，在寫各自的undo log時不產(chǎn)生沖突，InnoDB采用回滾段的方式來維護undo log的并發(fā)寫入和持久化。回滾段實際上是一種 Undo 文件組織方式。
ReadView
對于 RU(READ UNCOMMITTED) 隔離級別下，所有事務直接讀取數(shù)據(jù)庫的最新值即可，和 SERIALIZABLE 隔離級別，所有請求都會加鎖，同步執(zhí)行。所以這對這兩種情況下是不需要使用到 Read View 的版本控制。
對于 RC(READ COMMITTED) 和 RR(REPEATABLE READ) 隔離級別的實現(xiàn)就是通過上面的版本控制來完成。兩種隔離界別下的核心處理邏輯就是判斷所有版本中哪個版本是當前事務可見的處理。針對這個問題InnoDB在設計上增加了ReadView的設計，ReadView中主要包含當前系統(tǒng)中還有哪些活躍的讀寫事務，把它們的事務id放到一個列表中，我們把這個列表命名為為m_ids。
對于查詢時的版本鏈數(shù)據(jù)是否看見的判斷邏輯：
如果被訪問版本的 trx_id 屬性值小于 m_ids 列表中最小的事務id，表明生成該版本的事務在生成 ReadView 前已經(jīng)提交，所以該版本可以被當前事務訪問。
如果被訪問版本的 trx_id 屬性值大于 m_ids 列表中最大的事務id，表明生成該版本的事務在生成 ReadView 后才生成，所以該版本不可以被當前事務訪問。
如果被訪問版本的 trx_id 屬性值在 m_ids 列表中最大的事務id和最小事務id之間，那就需要判斷一下 trx_id 屬性值是不是在 m_ids 列表中，如果在，說明創(chuàng)建 ReadView 時生成該版本的事務還是活躍的，該版本不可以被訪問；如果不在，說明創(chuàng)建 ReadView 時生成該版本的事務已經(jīng)被提交，該版本可以被訪問。
舉個例子：
READ COMMITTED 隔離級別下的ReadView
每次讀取數(shù)據(jù)前都生成一個ReadView (m_ids列表)
| 時間 | Transaction 777 | Transaction 888 | Trasaction 999 |
|---|---|---|---|
| T1 | begin; | ||
| T2 | begin; | begin； | |
| T3 | UPDATE user SET name = 'CR7' WHERE id = 1; | ||
| T4 | ... | ||
| T5 | UPDATE user SET name = 'Messi' WHERE id = 1; | SELECT * FROM user where id = 1; | |
| T6 | commit; | ||
| T7 | UPDATE user SET name = 'Neymar' WHERE id = 1; | ||
| T8 | SELECT * FROM user where id = 1; | ||
| T9 | UPDATE user SET name = 'Dybala' WHERE id = 1; | ||
| T10 | commit; | ||
| T11 | SELECT * FROM user where id = 1; |
這里分析下上面的情況下的ReadView
時間點 T5 情況下的 SELECT 語句：
當前時間點的版本鏈：
此時 SELECT 語句執(zhí)行，當前數(shù)據(jù)的版本鏈如上，因為當前的事務777，和事務888 都未提交，所以此時的活躍事務的ReadView的列表情況 m_ids：[777, 888] ，因此查詢語句會根據(jù)當前版本鏈中小于 m_ids 中的最大的版本數(shù)據(jù)，即查詢到的是 Mbappe。
時間點 T8 情況下的 SELECT 語句：
當前時間的版本鏈情況：
此時 SELECT 語句執(zhí)行，當前數(shù)據(jù)的版本鏈如上，因為當前的事務777已經(jīng)提交，和事務888 未提交，所以此時的活躍事務的ReadView的列表情況 m_ids：[888] ，因此查詢語句會根據(jù)當前版本鏈中小于 m_ids 中的最大的版本數(shù)據(jù)，即查詢到的是 Messi。
時間點 T11 情況下的 SELECT 語句：
當前時間點的版本鏈信息：
此時 SELECT 語句執(zhí)行，當前數(shù)據(jù)的版本鏈如上，因為當前的事務777和事務888 都已經(jīng)提交，所以此時的活躍事務的ReadView的列表為空 ，因此查詢語句會直接查詢當前數(shù)據(jù)庫最新數(shù)據(jù)，即查詢到的是 Dybala。
總結： 使用READ COMMITTED隔離級別的事務在每次查詢開始時都會生成一個獨立的 ReadView。
REPEATABLE READ 隔離級別下的ReadView
在事務開始后第一次讀取數(shù)據(jù)時生成一個ReadView（m_ids列表）
| 時間 | Transaction 777 | Transaction 888 | Trasaction 999 |
|---|---|---|---|
| T1 | begin; | ||
| T2 | begin; | begin； | |
| T3 | UPDATE user SET name = 'CR7' WHERE id = 1; | ||
| T4 | ... | ||
| T5 | UPDATE user SET name = 'Messi' WHERE id = 1; | SELECT * FROM user where id = 1; | |
| T6 | commit; | ||
| T7 | UPDATE user SET name = 'Neymar' WHERE id = 1; | ||
| T8 | SELECT * FROM user where id = 1; | ||
| T9 | UPDATE user SET name = 'Dybala' WHERE id = 1; | ||
| T10 | commit; | ||
| T11 | SELECT * FROM user where id = 1; |
時間點 T5 情況下的 SELECT 語句：
當前版本鏈：
再當前執(zhí)行select語句時生成一個ReadView，此時 m_ids 內(nèi)容是：[777,888]，所以但前根據(jù)ReadView可見版本查詢到的數(shù)據(jù)為 Mbappe。
時間點 T8 情況下的 SELECT 語句：
當前的版本鏈：
此時在當前的 Transaction 999 的事務里。由于T5的時間點已經(jīng)生成了ReadView，所以再當前的事務中只會生成一次ReadView，所以此時依然沿用T5時的m_ids：[777,999]，所以此時查詢數(shù)據(jù)依然是 Mbappe。
時間點 T11 情況下的 SELECT 語句：
當前的版本鏈：
此時情況跟T8完全一樣。由于T5的時間點已經(jīng)生成了ReadView，所以再當前的事務中只會生成一次ReadView，所以此時依然沿用T5時的m_ids：[777,999]，所以此時查詢數(shù)據(jù)依然是 Mbappe。
感謝各位的閱讀，以上就是“MySQL事務和MVCC怎么實現(xiàn)隔離級別”的內(nèi)容了，經(jīng)過本文的學習后，相信大家對MySQL事務和MVCC怎么實現(xiàn)隔離級別這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！
免責聲明：本站發(fā)布的內(nèi)容（圖片、視頻和文字）以原創(chuàng)、轉載和分享為主，文章觀點不代表本網(wǎng)站立場，如果涉及侵權請聯(lián)系站長郵箱：is@yisu.com進行舉報，并提供相關證據(jù)，一經(jīng)查實，將立刻刪除涉嫌侵權內(nèi)容。
