[[345914]]

本文轉(zhuǎn)載自微信公眾號(hào)「三太子敖丙」，作者三太子敖丙。轉(zhuǎn)載本文請聯(lián)系三太子敖丙公眾號(hào)。 

前言

其實(shí)數(shù)據(jù)庫章節(jié)基本上的知識(shí)點(diǎn)我都寫過一遍了，包括這篇事務(wù)和MVCC的，但是國慶期間我翻閱資料的時(shí)候我發(fā)現(xiàn)之前寫的還差點(diǎn)意思，例子舉得也差點(diǎn)意思，那我就根據(jù)我自己最新的理解，加上之前的總結(jié)相當(dāng)于重寫了，希望你也有新的收獲。

數(shù)據(jù)庫事務(wù)

介紹事務(wù)的四大特性(ACID)

1. 原子性(atomicity)： 事務(wù)的最小工作單元，要么全成功，要么全失敗。
2. 一致性(consistency)： 事務(wù)開始和結(jié)束后，數(shù)據(jù)庫的完整性不會(huì)被破壞。
3. 隔離性(isolation)： 不同事務(wù)之間互不影響，四種隔離級(jí)別為RU(讀未提交)、RC(讀已提交)、RR(可重復(fù)讀)、SERIALIZABLE (串行化)。
4. 持久性(durability)： 事務(wù)提交后，對數(shù)據(jù)的修改是永久性的，即使系統(tǒng)故障也不會(huì)丟失。

事務(wù)的隔離級(jí)別

讀未提交(Read UnCommitted/RU)

又稱為臟讀，一個(gè)事務(wù)可以讀取到另一個(gè)事務(wù)未提交的數(shù)據(jù)。這種隔離級(jí)別歲最不安全的一種，因?yàn)槲刺峤坏氖聞?wù)是存在回滾的情況。

讀已提交(Read Committed/RC)

又稱為不可重復(fù)讀，一個(gè)事務(wù)因?yàn)樽x取到另一個(gè)事務(wù)已提交的修改數(shù)據(jù)，導(dǎo)致在當(dāng)前事務(wù)的不同時(shí)間讀取同一條數(shù)據(jù)獲取的結(jié)果不一致。

舉個(gè)例子，在下面的例子中就會(huì)發(fā)現(xiàn)SessionA在一個(gè)事務(wù)期間兩次查詢的數(shù)據(jù)不一樣。原因就是在于當(dāng)前隔離級(jí)別為 RC，SessionA的事務(wù)可以讀取到SessionB提交的最新數(shù)據(jù)。

可重復(fù)讀(Repeatable Read/RR)

又稱為幻讀，一個(gè)事物讀可以讀取到其他事務(wù)提交的數(shù)據(jù)，但是在RR隔離級(jí)別下，當(dāng)前讀取此條數(shù)據(jù)只可讀取一次，在當(dāng)前事務(wù)中，不論讀取多少次，數(shù)據(jù)任然是第一次讀取的值，不會(huì)因?yàn)樵诘谝淮巫x取之后，其他事務(wù)再修改提交此數(shù)據(jù)而產(chǎn)生改變。因此也成為幻讀，因?yàn)樽x出來的數(shù)據(jù)并不一定就是最新的數(shù)據(jù)。

舉個(gè)例子：在SessionA中第一次讀取數(shù)據(jù)時(shí)，后續(xù)其他事務(wù)修改提交數(shù)據(jù)，不會(huì)再影響到SessionA讀取的數(shù)據(jù)值。此為可重復(fù)讀。

串行化(Serializable)

所有的數(shù)據(jù)庫的讀或者寫操作都為串行執(zhí)行，當(dāng)前隔離級(jí)別下只支持單個(gè)請求同時(shí)執(zhí)行，所有的操作都需要隊(duì)列執(zhí)行。所以種隔離級(jí)別下所有的數(shù)據(jù)是最穩(wěn)定的，但是性能也是最差的。數(shù)據(jù)庫的鎖實(shí)現(xiàn)就是這種隔離級(jí)別的更小粒度版本。

事務(wù)和MVCC原理不同事務(wù)同時(shí)操作同一條數(shù)據(jù)產(chǎn)生的問題

示例：

上面的兩種情況就是對于一條數(shù)據(jù)，多個(gè)事務(wù)同時(shí)操作可能會(huì)產(chǎn)生的問題，會(huì)出現(xiàn)某個(gè)事務(wù)的操作被覆蓋而導(dǎo)致數(shù)據(jù)丟失。

LBCC 解決數(shù)據(jù)丟失

LBCC，基于鎖的并發(fā)控制，Lock Based Concurrency Control。

使用鎖的機(jī)制，在當(dāng)前事務(wù)需要對數(shù)據(jù)修改時(shí)，將當(dāng)前事務(wù)加上鎖，同一個(gè)時(shí)間只允許一條事務(wù)修改當(dāng)前數(shù)據(jù)，其他事務(wù)必須等待鎖釋放之后才可以操作。

MVCC 解決數(shù)據(jù)丟失

MVCC，多版本的并發(fā)控制，Multi-Version Concurrency Control。

使用版本來控制并發(fā)情況下的數(shù)據(jù)問題，在B事務(wù)開始修改賬戶且事務(wù)未提交時(shí)，當(dāng)A事務(wù)需要讀取賬戶余額時(shí)，此時(shí)會(huì)讀取到B事務(wù)修改操作之前的賬戶余額的副本數(shù)據(jù)，但是如果A事務(wù)需要修改賬戶余額數(shù)據(jù)就必須要等待B事務(wù)提交事務(wù)。

MVCC使得數(shù)據(jù)庫讀不會(huì)對數(shù)據(jù)加鎖，普通的SELECT請求不會(huì)加鎖，提高了數(shù)據(jù)庫的并發(fā)處理能力。借助MVCC，數(shù)據(jù)庫可以實(shí)現(xiàn)READ COMMITTED，REPEATABLE READ等隔離級(jí)別，用戶可以查看當(dāng)前數(shù)據(jù)的前一個(gè)或者前幾個(gè)歷史版本，保證了ACID中的I特性(隔離性)。

InnoDB的MVCC實(shí)現(xiàn)邏輯

InnoDB存儲(chǔ)引擎保存的MVCC的數(shù)據(jù)

InnoDB的MVCC是通過在每行記錄后面保存兩個(gè)隱藏的列來實(shí)現(xiàn)的。一個(gè)保存了行的事務(wù)ID(DB_TRX_ID)，一個(gè)保存了行的回滾指針(DB_ROLL_PT)。每開始一個(gè)新的事務(wù)，都會(huì)自動(dòng)遞增產(chǎn) 生一個(gè)新的事務(wù)id。事務(wù)開始時(shí)刻的會(huì)把事務(wù)id放到當(dāng)前事務(wù)影響的行事務(wù)id中，當(dāng)查詢時(shí)需要用當(dāng)前事務(wù)id和每行記錄的事務(wù)id進(jìn)行比較。

下面看一下在REPEATABLE READ隔離級(jí)別下，MVCC具體是如何操作的。

SELECT

InnoDB 會(huì)根據(jù)以下兩個(gè)條件檢查每行記錄：

1. InnoDB只查找版本早于當(dāng)前事務(wù)版本的數(shù)據(jù)行(也就是，行的事務(wù)編號(hào)小于或等于當(dāng)前事務(wù)的事務(wù)編號(hào))，這樣可以確保事務(wù)讀取的行，要么是在事務(wù)開始前已經(jīng)存在的，要么是事務(wù)自身插入或者修改過的。
2. 刪除的行要事務(wù)ID判斷，讀取到事務(wù)開始之前狀態(tài)的版本，只有符合上述兩個(gè)條件的記錄，才能返回作為查詢結(jié)果。

INSERT

InnoDB為新插入的每一行保存當(dāng)前事務(wù)編號(hào)作為行版本號(hào)。

DELETE

InnoDB為刪除的每一行保存當(dāng)前事務(wù)編號(hào)作為行刪除標(biāo)識(shí)。

UPDATE

InnoDB為插入一行新記錄，保存當(dāng)前事務(wù)編號(hào)作為行版本號(hào)，同時(shí)保存當(dāng)前事務(wù)編號(hào)到原來的行作為行刪除標(biāo)識(shí)。

保存這兩個(gè)額外事務(wù)編號(hào)，使大多數(shù)讀操作都可以不用加鎖。這樣設(shè)計(jì)使得讀數(shù)據(jù)操作很簡單，性能很好，并且也能保證只會(huì)讀取到符合標(biāo)準(zhǔn)的行。不足之處是每行記錄都需要額外的存儲(chǔ)空間，需要做更多的行檢查工作，以及一些額外的維護(hù)工作。

MVCC只在REPEATABLE READ和READ COMMITIED兩個(gè)隔離級(jí)別下工作。其他兩個(gè)隔離級(jí)別都和 MVCC不兼容 ，因?yàn)镽EAD UNCOMMITIED總是讀取最新的數(shù)據(jù)行，而不是符合當(dāng)前事務(wù)版本的數(shù)據(jù)行。而SERIALIZABLE則會(huì)對所有讀取的行都加鎖。

MVCC 在mysql 中的實(shí)現(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，因?yàn)閕nsert操作記錄只對當(dāng)前事務(wù)本身課件，對于其他事務(wù)此記錄不可見，所以 insert undo log 可以在事務(wù)提交后直接刪除而不需要進(jìn)行purge操作。

purge的主要任務(wù)是將數(shù)據(jù)庫中已經(jīng) mark del 的數(shù)據(jù)刪除，另外也會(huì)批量回收undo pages

數(shù)據(jù)庫 Insert時(shí)的數(shù)據(jù)初始狀態(tài)：

• update undo log：

update 或 delete 操作中產(chǎn)生的 undo log。因?yàn)闀?huì)對已經(jīng)存在的記錄產(chǎn)生影響，為了提供 MVCC機(jī)制，因此update undo log 不能在事務(wù)提交時(shí)就進(jìn)行刪除，而是將事務(wù)提交時(shí)放到入 history list 上，等待 purge 線程進(jìn)行最后的刪除操作。

數(shù)據(jù)第一次被修改時(shí)：

當(dāng)另一個(gè)事務(wù)第二次修改當(dāng)前數(shù)據(jù)：

為了保證事務(wù)并發(fā)操作時(shí)，在寫各自的undo log時(shí)不產(chǎn)生沖突，InnoDB采用回滾段的方式來維護(hù)undo log的并發(fā)寫入和持久化?；貪L段實(shí)際上是一種 Undo 文件組織方式。

ReadView

對于 RU(READ UNCOMMITTED) 隔離級(jí)別下，所有事務(wù)直接讀取數(shù)據(jù)庫的最新值即可，和 SERIALIZABLE 隔離級(jí)別，所有請求都會(huì)加鎖，同步執(zhí)行。所以這對這兩種情況下是不需要使用到 Read View 的版本控制。

對于 RC(READ COMMITTED) 和 RR(REPEATABLE READ) 隔離級(jí)別的實(shí)現(xiàn)就是通過上面的版本控制來完成。兩種隔離界別下的核心處理邏輯就是判斷所有版本中哪個(gè)版本是當(dāng)前事務(wù)可見的處理。針對這個(gè)問題InnoDB在設(shè)計(jì)上增加了ReadView的設(shè)計(jì)，ReadView中主要包含當(dāng)前系統(tǒng)中還有哪些活躍的讀寫事務(wù)，把它們的事務(wù)id放到一個(gè)列表中，我們把這個(gè)列表命名為為m_ids。

對于查詢時(shí)的版本鏈數(shù)據(jù)是否看見的判斷邏輯：

• 如果被訪問版本的 trx_id 屬性值小于 m_ids 列表中最小的事務(wù)id，表明生成該版本的事務(wù)在生成 ReadView 前已經(jīng)提交，所以該版本可以被當(dāng)前事務(wù)訪問。
• 如果被訪問版本的 trx_id 屬性值大于 m_ids 列表中最大的事務(wù)id，表明生成該版本的事務(wù)在生成 ReadView 后才生成，所以該版本不可以被當(dāng)前事務(wù)訪問。
• 如果被訪問版本的 trx_id 屬性值在 m_ids 列表中最大的事務(wù)id和最小事務(wù)id之間，那就需要判斷一下 trx_id 屬性值是不是在 m_ids 列表中，如果在，說明創(chuàng)建 ReadView 時(shí)生成該版本的事務(wù)還是活躍的，該版本不可以被訪問;如果不在，說明創(chuàng)建 ReadView 時(shí)生成該版本的事務(wù)已經(jīng)被提交，該版本可以被訪問。

舉個(gè)例子：

READ COMMITTED 隔離級(jí)別下的ReadView

每次讀取數(shù)據(jù)前都生成一個(gè)ReadView (m_ids列表)

這里分析下上面的情況下的ReadView

時(shí)間點(diǎn) T5 情況下的 SELECT 語句：

當(dāng)前時(shí)間點(diǎn)的版本鏈：

此時(shí) SELECT 語句執(zhí)行，當(dāng)前數(shù)據(jù)的版本鏈如上，因?yàn)楫?dāng)前的事務(wù)777，和事務(wù)888 都未提交，所以此時(shí)的活躍事務(wù)的ReadView的列表情況 m_ids：[777, 888] ，因此查詢語句會(huì)根據(jù)當(dāng)前版本鏈中小于 m_ids 中的最大的版本數(shù)據(jù)，即查詢到的是 Mbappe。

時(shí)間點(diǎn) T8 情況下的 SELECT 語句：

當(dāng)前時(shí)間的版本鏈情況：

此時(shí) SELECT 語句執(zhí)行，當(dāng)前數(shù)據(jù)的版本鏈如上，因?yàn)楫?dāng)前的事務(wù)777已經(jīng)提交，和事務(wù)888 未提交，所以此時(shí)的活躍事務(wù)的ReadView的列表情況 m_ids：[888] ，因此查詢語句會(huì)根據(jù)當(dāng)前版本鏈中小于 m_ids 中的最大的版本數(shù)據(jù)，即查詢到的是 Messi。

時(shí)間點(diǎn) T11 情況下的 SELECT 語句：

當(dāng)前時(shí)間點(diǎn)的版本鏈信息：

此時(shí) SELECT 語句執(zhí)行，當(dāng)前數(shù)據(jù)的版本鏈如上，因?yàn)楫?dāng)前的事務(wù)777和事務(wù)888 都已經(jīng)提交，所以此時(shí)的活躍事務(wù)的ReadView的列表為空 ，因此查詢語句會(huì)直接查詢當(dāng)前數(shù)據(jù)庫最新數(shù)據(jù)，即查詢到的是 Dybala。

總結(jié)： 使用READ COMMITTED隔離級(jí)別的事務(wù)在每次查詢開始時(shí)都會(huì)生成一個(gè)獨(dú)立的 ReadView。

REPEATABLE READ 隔離級(jí)別下的ReadView

在事務(wù)開始后第一次讀取數(shù)據(jù)時(shí)生成一個(gè)ReadView(m_ids列表)

時(shí)間點(diǎn) T5 情況下的 SELECT 語句：

當(dāng)前版本鏈：

再當(dāng)前執(zhí)行select語句時(shí)生成一個(gè)ReadView，此時(shí) m_ids 內(nèi)容是：[777,888]，所以但前根據(jù)ReadView可見版本查詢到的數(shù)據(jù)為 Mbappe。

時(shí)間點(diǎn) T8 情況下的 SELECT 語句：

當(dāng)前的版本鏈：

此時(shí)在當(dāng)前的 Transaction 999 的事務(wù)里。由于T5的時(shí)間點(diǎn)已經(jīng)生成了ReadView，所以再當(dāng)前的事務(wù)中只會(huì)生成一次ReadView，所以此時(shí)依然沿用T5時(shí)的m_ids：[777,999]，所以此時(shí)查詢數(shù)據(jù)依然是 Mbappe。

時(shí)間點(diǎn) T11 情況下的 SELECT 語句：

當(dāng)前的版本鏈：

此時(shí)情況跟T8完全一樣。由于T5的時(shí)間點(diǎn)已經(jīng)生成了ReadView，所以再當(dāng)前的事務(wù)中只會(huì)生成一次ReadView，所以此時(shí)依然沿用T5時(shí)的m_ids：[777,999]，所以此時(shí)查詢數(shù)據(jù)依然是 Mbappe。

MVCC總結(jié)：

所謂的MVCC(Multi-Version Concurrency Control ，多版本并發(fā)控制)指的就是在使用READ COMMITTD 、REPEATABLE READ 這兩種隔離級(jí)別的事務(wù)在執(zhí)行普通的 SEELCT 操作時(shí)訪問記錄的版本鏈的過程，這樣子可以使不同事務(wù)的 讀-寫 、 寫-讀 操作并發(fā)執(zhí)行，從而提升系統(tǒng)性能。

在 MySQL 中， READ COMMITTED 和 REPEATABLE READ 隔離級(jí)別的的一個(gè)非常大的區(qū)別就是它們生成 ReadView 的時(shí)機(jī)不同。在 READ COMMITTED 中每次查詢都會(huì)生成一個(gè)實(shí)時(shí)的 ReadView，做到保證每次提交后的數(shù)據(jù)是處于當(dāng)前的可見狀態(tài)。而 REPEATABLE READ 中，在當(dāng)前事務(wù)第一次查詢時(shí)生成當(dāng)前的 ReadView，并且當(dāng)前的 ReadView 會(huì)一直沿用到當(dāng)前事務(wù)提交，以此來保證可重復(fù)讀(REPEATABLE READ)。

好啦以上就是本期的全部內(nèi)容了，如果你覺得寫得不錯(cuò)，請給我一個(gè)免費(fèi)的在看，你知道的越多，你不知道的越多，我是敖丙，我們下期見，拜拜!