[[376055]]

本文轉(zhuǎn)載自微信公眾號(hào)「菜鳥飛呀飛」，作者劉進(jìn)坤。轉(zhuǎn)載本文請(qǐng)聯(lián)系菜鳥飛呀飛公眾號(hào)。   

 undo log 版本鏈

在 MySQL 的數(shù)據(jù)表中，存儲(chǔ)著一行行的數(shù)據(jù)記錄，對(duì)每行數(shù)據(jù)而言，不僅僅記錄著我們定義的字段值，還會(huì)隱藏兩個(gè)字段：row_trx_id 和 roll_pointer，前者表示更新本行數(shù)據(jù)的事務(wù) id，后者表示的是回滾指針，它指向的是該行數(shù)據(jù)上一個(gè)版本的 undo log(如果不明白這是什么，可以先繼續(xù)往后看)。

對(duì)于每行有兩個(gè)隱藏的字段，在《高性能 MySQL》第三版的第 13 頁中把它們叫做數(shù)據(jù)的更新時(shí)間和過期時(shí)間，這兩個(gè)字段存儲(chǔ)的不是真實(shí)的時(shí)間，而是事務(wù)的版本號(hào)。

這與本文 row_trx_id 和 roll_pointer 的叫法差異很大，實(shí)際上，不用在意這兩個(gè)字段具體叫什么，反正它們都是為了實(shí)現(xiàn) MVCC 機(jī)制而設(shè)計(jì)的。

我個(gè)人覺得把它們分別叫做 row_trx_id 和 roll_pointer，會(huì)更容易理解一點(diǎn)。

我們知道，當(dāng)我們進(jìn)行數(shù)據(jù)的新增、刪除、修改操作時(shí)，會(huì)寫 redo log(解決數(shù)據(jù)庫宕機(jī)重啟丟失數(shù)據(jù)的問題)和 binlog(主要用來做復(fù)制、數(shù)據(jù)備份等操作)，另外還會(huì)寫 undo log，它是為了實(shí)現(xiàn)事務(wù)的回滾操作。

每一條 undo log 的具體內(nèi)容本文今天先不解釋，有興趣的同學(xué)可以自行網(wǎng)上查閱。我們只需要知道每行 undo log 日志會(huì)記錄對(duì)應(yīng)的事務(wù) id，還會(huì)記錄當(dāng)前事務(wù)將數(shù)據(jù)修改后的最新值，以及指向當(dāng)前行數(shù)據(jù)上一個(gè)版本的 undo log 的指針，也就是 roll_pointer。

為了方便理解，每一行 undo log 可以簡化為下圖所示的結(jié)構(gòu)：

圖1

舉個(gè)例子，現(xiàn)在有一個(gè)事務(wù) A，它的事務(wù) id 為 10，向表中新插入了一條數(shù)據(jù)，數(shù)據(jù)記為 data_A，那么此時(shí)對(duì)應(yīng)的 undo log 應(yīng)該如下圖所示：

圖2

由于是新插入的一條數(shù)據(jù)，所以這行數(shù)據(jù)是第一個(gè)版本，也就是它沒有上一個(gè)數(shù)據(jù)版本，因此它的 roll_pointer 為 null。

接著事務(wù) B(trx_id=20)，將這行數(shù)據(jù)的值修改為 data_B，同樣也會(huì)記錄一條 undo log，如下圖所示，這條 undo log 的 roll_pointer 指針會(huì)指向上一個(gè)數(shù)據(jù)版本的 undo log，也就是指向事務(wù) A 寫入的那一行 undo log。

圖3

再接著，事務(wù) C(trx_id=30)，將這行數(shù)據(jù)的值修改為 data_C，對(duì)應(yīng)的示意圖如下。

圖4

只要有事務(wù)修改了這一行的數(shù)據(jù)，那么就會(huì)記錄一條對(duì)應(yīng)的 undo log，一條 undo log 對(duì)應(yīng)這行數(shù)據(jù)的一個(gè)版本，當(dāng)這行數(shù)據(jù)有多個(gè)版本時(shí)，就會(huì)有多條 undo log 日志，undo log 之間通過 roll_pointer 指針連接，這樣就形成了一個(gè) undo log 版本鏈

ReadView 機(jī)制

當(dāng)事務(wù)在開始執(zhí)行的時(shí)候，會(huì)給每個(gè)事務(wù)生成一個(gè) ReadView。這個(gè) ReadView 會(huì)記錄 4 個(gè)非常重要的屬性：

1. creator_trx_id: 當(dāng)前事務(wù)的 id;
2. m_ids: 當(dāng)前系統(tǒng)中所有的活躍事務(wù)的 id，活躍事務(wù)指的是當(dāng)前系統(tǒng)中開啟了事務(wù)，但是還沒有提交的事務(wù);
3. min_trx_id: 當(dāng)前系統(tǒng)中，所有活躍事務(wù)中事務(wù) id 最小的那個(gè)事務(wù)，也就是 m_id 數(shù)組中最小的事務(wù) id;
4. max_trx_id: 當(dāng)前系統(tǒng)中事務(wù)的 id 值最大的那個(gè)事務(wù) id 值再加 1，也就是系統(tǒng)中下一個(gè)要生成的事務(wù) id。

ReadView 會(huì)根據(jù)這 4 個(gè)屬性，再結(jié)合 undo log 版本鏈，來實(shí)現(xiàn) MVCC 機(jī)制，決定讓一個(gè)事務(wù)能讀取到哪些數(shù)據(jù)，不能讀取到哪些數(shù)據(jù)。

那么到底是如何來實(shí)現(xiàn)的呢?

如果用一個(gè)坐標(biāo)軸來表示的話，min_trx_id 和 max_trx_id 會(huì)將這個(gè)坐標(biāo)軸分成 3 個(gè)部分：

圖5

當(dāng)一個(gè)事務(wù)讀取某條數(shù)據(jù)時(shí)，就會(huì)按照如下規(guī)則來決定當(dāng)前事務(wù)能讀取到什么數(shù)據(jù)：

1. 如果當(dāng)前數(shù)據(jù)的 row_trx_id 小于 min_trx_id，那么表示這條數(shù)據(jù)是在當(dāng)前事務(wù)開啟之前，其他的事務(wù)就已經(jīng)將該條數(shù)據(jù)修改了并提交了事務(wù)(事務(wù)的 id 值是遞增的)，所以當(dāng)前事務(wù)能讀取到。
2. 如果當(dāng)前數(shù)據(jù)的 row_trx_id 大于等于 max_trx_id，那么表示在當(dāng)前事務(wù)開啟以后，過了一段時(shí)間，系統(tǒng)中有新的事務(wù)開啟了，并且新的事務(wù)修改了這行數(shù)據(jù)的值并提交了事務(wù)，所以當(dāng)前事務(wù)肯定是不能讀取到的，因此這是后面的事務(wù)修改提交的數(shù)據(jù)。
3. 如果當(dāng)前數(shù)據(jù)的 row_trx_id 處于 min_trx_id 和 max_trx_id 的范圍之間，又需要分兩種情況：

(a)row_trx_id 在 m_ids 數(shù)組中，那么當(dāng)前事務(wù)不能讀取到。為什么呢?row_trx_id 在 m_ids 數(shù)組中表示的是和當(dāng)前事務(wù)在同一時(shí)刻開啟的事務(wù)，修改了數(shù)據(jù)的值，并提交了事務(wù)，所以不能讓當(dāng)前事務(wù)讀取到;

(b) row_trx_id 不在 m_ids 數(shù)組中，那么當(dāng)前事務(wù)能讀取到。row_trx_id 不在 m_ids 數(shù)組中表示的是在當(dāng)前事務(wù)開啟之前，其他事務(wù)將數(shù)據(jù)修改后就已經(jīng)提交了事務(wù)，所以當(dāng)前事務(wù)能讀取到。

注意：如果 row_trx_id 等于當(dāng)前事務(wù)的 id，那表示這條數(shù)據(jù)就是當(dāng)前事務(wù)修改的，那當(dāng)前事務(wù)肯定能讀取到啊。

這里可能有人會(huì)有一個(gè)疑惑，事務(wù)的 id 值是遞增的，那么在什么場景下，row_trx_id 處于 min_trx_id 和 max_trx_id 之間，但是卻又不再 m_id 數(shù)組內(nèi)呢?

這個(gè)問題也是困擾了我很長一段時(shí)間，最近終于想通了，答案就是在讀提交的事務(wù)隔離級(jí)別下，會(huì)出現(xiàn)這種現(xiàn)象。

至于為什么，需要看完這一篇文章以及下下一篇文章《在讀提交的事務(wù)隔離級(jí)別下，MVCC 機(jī)制是如何工作的?》，才能明白為什么。

下面舉幾個(gè)例子，來解釋一下 ReadView 機(jī)制下，數(shù)據(jù)的讀取規(guī)則。先假設(shè)表中有一條數(shù)據(jù)，它的 row_trx_id=10，roll_pointer 為 null，那么此時(shí) undo log 版本鏈就是下圖這樣：

圖6

假設(shè)現(xiàn)在有事務(wù) A 和事務(wù) B 并發(fā)執(zhí)行，事務(wù) A 的事務(wù) id 為 20，事務(wù) B 的事務(wù) id 為 30。

那么此時(shí)對(duì)于事務(wù) A 而言，它的 ReadView 中，m_ids=[20,30]，min_trx_id=20，max_trx_id=31，creator_trx_id=20。

對(duì)于事務(wù) B 而言，它的 ReadView 中，m_ids=[20,30]，min_trx_id=20，max_trx_id=31，creator_trx_id=30。

如果此時(shí)事務(wù) A(trx_id=20)去讀取數(shù)據(jù)，那么在 undo log 版本鏈中，數(shù)據(jù)最新版本的事務(wù) id 為 10，這個(gè)值小于事務(wù) A 的 ReadView 里 min_trx_id 的值，這表示這個(gè)數(shù)據(jù)的版本是事務(wù) A 開啟之前，其他事務(wù)提交的，因此事務(wù) A 可以讀取到，所以讀取到的值是 data0。

圖7

接著事務(wù) B(trx_id=30)去修改數(shù)據(jù)，將數(shù)據(jù)修改為 data_B，先不提交事務(wù)。雖然不提交事務(wù)，但是仍然會(huì)記錄一條 undo log，因此這條數(shù)據(jù)的 undo log 的版本鏈就有兩條記錄了，新的這條 undo log 的 roll_pointer 指針會(huì)指向前一條 undo log，示意圖如下。

圖8

接著事務(wù) A(trx_id=20)去讀取數(shù)據(jù)，那么在 undo log 版本鏈中，數(shù)據(jù)最新版本的事務(wù) id 為 30，這個(gè)值處于事務(wù) A 的 ReadView 里 min_trx_id 和 max_trx_id 之間，因此還需要判斷這個(gè)數(shù)據(jù)版本的值是否在 m_ids 數(shù)組中，結(jié)果發(fā)現(xiàn)，30 確實(shí)在 m_ids 數(shù)組中，這表示這個(gè)版本的數(shù)據(jù)是和自己同一時(shí)刻啟動(dòng)的事務(wù)修改的，因此這個(gè)版本的數(shù)據(jù)，數(shù)據(jù) A 讀取不到。所以需要沿著 undo log 的版本鏈向前找，接著會(huì)找到該行數(shù)據(jù)的上一個(gè)版本，也就是 trx_id=10 的版本，由于這個(gè)版本的數(shù)據(jù)的 trx_id=10，小于 min_trx_id 的值，因此事務(wù) A 能讀取到該版本的值，即事務(wù) A 讀取到的值是 data0。

圖9

緊接著事務(wù) B 提交事務(wù)，那么此時(shí)系統(tǒng)中活躍的事務(wù)就只有 id 為 20 的事務(wù)了，也就是事務(wù) A。那么此時(shí)事務(wù) A 再去讀取數(shù)據(jù)，它能讀取到什么值呢?還是 data0。為什么呢?

雖然系統(tǒng)中當(dāng)前只剩下 id 為 20 的活躍事務(wù)了，但是事務(wù) A 開啟的瞬間，它已經(jīng)生成了 ReadView ，后面即使有其他事務(wù)提交了，但是事務(wù) A 的 ReadView 不會(huì)修改，也就是 m_ids 不會(huì)變，還是 m_ids=[20,30]，所以此時(shí)事務(wù) A 去根據(jù) undo log 版本鏈去讀取數(shù)據(jù)時(shí)，還是不能讀取最新版本的數(shù)據(jù)，只能往前找，最終還是只能讀取到 data0。

接著系統(tǒng)中，新開了一個(gè)事務(wù) C，事務(wù) id 為 40，它的 ReadView 中，m_ids=[20,40]，min_trx_id=20，max_trx_id=41，creator_trx_id=40。

然后事務(wù) C(trx_id=40)將數(shù)據(jù)修改為 data_C，并提交事務(wù)。此時(shí) undo log 版本鏈就變成了如下圖所示。

圖10

此時(shí)事務(wù) A(trx_id=20)去讀取數(shù)據(jù)，那么在 undo log 版本鏈中，數(shù)據(jù)最新版本的事務(wù) id 為 40，由于此時(shí)事務(wù) A 的 ReadView 中的 max_trx_id=31，40 大于 31，這表示當(dāng)前版本的數(shù)據(jù)時(shí)在事務(wù) A 之后提交的，因此對(duì)于事務(wù) A 肯定是不能讀取到的。所以此時(shí)事務(wù) A 只能根據(jù) roll_pointer 指針，沿著 undo log 版本向前找，結(jié)果發(fā)現(xiàn)上一個(gè)版本的 trx_id=30，自己還是不能讀取到，所以再繼續(xù)往前找，最終可以讀取到 trx_id=10 的版本數(shù)據(jù)，因此最終事務(wù) A 只能讀取到 data0。

圖11

接著事務(wù) A(trx_id=20)去修改數(shù)據(jù)，將數(shù)據(jù)修改為 data_A，那么就會(huì)記錄一條 undo log，示意圖如下：

圖12

然后事務(wù) A(trx_id=20)再去讀取數(shù)據(jù)，在 undo log 版本鏈中，數(shù)據(jù)最新版本的事務(wù) id 為 20，事務(wù) A 一對(duì)比，發(fā)現(xiàn)該版本的事務(wù) id 與自己的事務(wù) id 相等，這表示這個(gè)版本的數(shù)據(jù)就是自己修改的，既然是自己修改的，那就肯定能讀取到了，因此此時(shí)讀取到是 data_A。

圖13

總結(jié)

總結(jié)一下，本文主要講解了 undo log 版本鏈?zhǔn)侨绾涡纬傻?，然后講解了 ReadView 的機(jī)制是什么，通過幾個(gè)例子，配合畫圖，詳細(xì)分析了 ReadView 結(jié)合 undo log 版本鏈?zhǔn)侨绾蝸韺?shí)現(xiàn)讓當(dāng)前事務(wù)讀取到哪一個(gè)版本的數(shù)據(jù)的，這也就是 MVCC 機(jī)制的核心實(shí)現(xiàn)原理。

但是到目前為止，只是分析了 ReadView 和 undo log 是如何來實(shí)現(xiàn) MVCC 機(jī)制，如何控制事務(wù)怎么讀取數(shù)據(jù)，還沒有結(jié)合在具體的事務(wù)隔離級(jí)別下，MVCC 機(jī)制是如何工作的。