一、數(shù)據(jù)準(zhǔn)備

為了我們學(xué)習(xí)的順利進(jìn)行，我們這邊創(chuàng)建一張 hero表

CREATE TABLE hero(
	number INT PRIMARY KEY,
	name VARCHAR(4),
	country VARCHAR(2)
);

這里需要注意的是，我們的 hero表的主鍵是number，而不是id，主要是后邊要用到的事務(wù)id做一下區(qū)別，然后我們給這個(gè)表里插入一條數(shù)據(jù)

mysql> INSERT INTO hero VALUES(1,'張角','東漢');
Query OK, 1 row affected (0.01 sec

現(xiàn)在我們表里的數(shù)據(jù)就是這樣：

mysql> SELECT * FROM hero;
+--------+--------+---------+
| number | name   | country |
+--------+--------+---------+
|      1 | 張角   | 東漢    |
+--------+--------+---------+
1 row in set (0.00 sec)

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

我們知道MySQL是CS架構(gòu)的軟件，若干個(gè)客戶端與服務(wù)器連接上之后，就可以稱之為一個(gè)會(huì)話（Session）。每個(gè)客戶端都可以在自己的會(huì)話中向服務(wù)器發(fā)出請(qǐng)求語(yǔ)句，一個(gè)請(qǐng)求語(yǔ)句可能是某個(gè)事務(wù)的一部分，也就是對(duì)于服務(wù)器來說可能同時(shí)處理多個(gè)事務(wù)。在事務(wù)簡(jiǎn)介的章節(jié)中我們說過事務(wù)有一個(gè)稱之為隔離性的特性，理論上在某個(gè)事務(wù)對(duì)某個(gè)數(shù)據(jù)進(jìn)行訪問時(shí)，其他事務(wù)應(yīng)該進(jìn)行排隊(duì)，當(dāng)該事務(wù)提交之后，其他事務(wù)才可以繼續(xù)訪問這個(gè)數(shù)據(jù)。但是這樣子的話對(duì)性能影響太大，我們既想保持事務(wù)的隔離性，又想讓服務(wù)器在處理訪問同一數(shù)據(jù)的多個(gè)事務(wù)時(shí)性能盡量高些，魚和熊掌不可得兼，舍一部分隔離性而取性能者也。

2.1 事務(wù)并發(fā)執(zhí)行遇到的問題

怎么個(gè)舍棄法呢？我們先得看一下訪問相同數(shù)據(jù)的事務(wù)在不保證串行執(zhí)行（也就是執(zhí)行完一個(gè)再執(zhí)行另一個(gè)）的情況下可能會(huì)出現(xiàn)哪些問題：

臟寫（Dirty Write）： 如果一個(gè)事務(wù)修改了另一個(gè)未提交事務(wù)修改過的數(shù)據(jù)，那就意味著發(fā)生了臟寫，示意圖如下：

如上表，Session A和Session B各開啟了一個(gè)事務(wù)，Session B中的事務(wù)先將number列為1的記錄的name列更新為'趙云'，然后Session A中的事務(wù)接著又把這條number列為1的記錄的name列更新為法正。如果之后Session B中的事務(wù)進(jìn)行了回滾，那么Session A中的更新也將不復(fù)存在，這種現(xiàn)象就稱之為臟寫。這時(shí)Session A中的事務(wù)就很懵逼，我明明把數(shù)據(jù)更新了，最后也提交事務(wù)了，怎么到最后說自己啥也沒干呢？

臟讀（Dirty Read） ：如果一個(gè)事務(wù)讀到了另一個(gè)未提交事務(wù)修改過的數(shù)據(jù)，那就意味著發(fā)生了臟讀，示意圖如下：

如上表，Session A和Session B各開啟了一個(gè)事務(wù)，Session B中的事務(wù)先將number列為1的記錄的name列更新為'趙云'，然后Session A中的事務(wù)再去查詢這條number為1的記錄，如果讀到列name的值為'趙云'，而Session B中的事務(wù)稍后進(jìn)行了回滾，那么Session A中的事務(wù)相當(dāng)于讀到了一個(gè)不存在的數(shù)據(jù)，這種現(xiàn)象就稱之為臟讀。

不可重復(fù)讀（Non-Repeatable Read）： 如果一個(gè)事務(wù)只能讀到另一個(gè)已經(jīng)提交的事務(wù)修改過的數(shù)據(jù)，并且其他事務(wù)每對(duì)該數(shù)據(jù)進(jìn)行一次修改并提交后，該事務(wù)都能查詢得到最新值，那就意味著發(fā)生了不可重復(fù)讀，示意圖如下：

如上表，我們?cè)?code>Session B中提交了幾個(gè)隱式事務(wù)（意味著語(yǔ)句結(jié)束事務(wù)就提交了），這些事務(wù)都修改了number列為1的記錄的列name的值，每次事務(wù)提交之后，如果Session A中的事務(wù)都可以查看到最新的值，這種現(xiàn)象也被稱之為不可重復(fù)讀。

幻讀（Phantom）： 如果一個(gè)事務(wù)先根據(jù)某些條件查詢出一些記錄，之后另一個(gè)事務(wù)又向表中插入了符合這些條件的記錄，原先的事務(wù)再次按照該條件查詢時(shí)，能把另一個(gè)事務(wù)插入的記錄也讀出來，那就意味著發(fā)生了幻讀，示意圖如下：

如上表，Session A中的事務(wù)先根據(jù)條件number > 0這個(gè)條件查詢表hero，得到了name列值為'張角'的記錄；之后Session B中提交了一個(gè)隱式事務(wù)，該事務(wù)向表hero中插入了一條新記錄；之后Session A中的事務(wù)再根據(jù)相同的條件number > 0查詢表hero，得到的結(jié)果集中包含Session B中的事務(wù)新插入的那條記錄，這種現(xiàn)象也被稱之為幻讀。

Q1: 如果Session B中是刪除了一些符合number > 0的記錄而不是插入新記錄，那Session A中之后再根據(jù)number > 0的條件讀取的記錄變少了，這種現(xiàn)象算不算幻讀呢？

W1: 明確說一下，這種現(xiàn)象不屬于幻讀，幻讀強(qiáng)調(diào)的是一個(gè)事務(wù)按照某個(gè)相同條件多次讀取記錄時(shí)，后讀取時(shí)讀到了之前沒有讀到的記錄。

小提士：
那對(duì)于先前已經(jīng)讀到的記錄，之后又讀取不到這種情況，算啥呢？其實(shí)這相當(dāng)于對(duì)每一條記錄都發(fā)生了不可重復(fù)讀的現(xiàn)象。幻讀只是重點(diǎn)強(qiáng)調(diào)了讀取到了之前讀取沒有獲取到的記錄。

2.2 SQL標(biāo)準(zhǔn)中的四種隔離級(jí)別

我們上邊介紹了幾種并發(fā)事務(wù)執(zhí)行過程中可能遇到的一些問題，這些問題也有輕重緩急之分，我們給這些問題按照嚴(yán)重性來排一下序：

臟寫 > 臟讀 > 不可重復(fù)讀 > 幻讀

我們上邊所說的舍棄一部分隔離性來?yè)Q取一部分性能在這里就體現(xiàn)在：設(shè)立一些隔離級(jí)別，隔離級(jí)別越低，越嚴(yán)重的問題就越可能發(fā)生。于是制定了一個(gè)所謂的SQL標(biāo)準(zhǔn)，在標(biāo)準(zhǔn)中設(shè)立了4個(gè)隔離級(jí)別：

• READ UNCOMMITTED：未提交讀
• READ COMMITTED：已提交讀
• REPEATABLE READ：可重復(fù)讀
• SERIALIZABLE：可串行化

SQL標(biāo)準(zhǔn)中規(guī)定，針對(duì)不同的隔離級(jí)別，并發(fā)事務(wù)可以發(fā)生不同嚴(yán)重程度的問題，具體情況如下：

也就是說：

• READ UNCOMMITTED隔離級(jí)別下，可能發(fā)生臟讀、不可重復(fù)讀和幻讀問題。
• READ COMMITTED隔離級(jí)別下，可能發(fā)生不可重復(fù)讀和幻讀問題，但是不可以發(fā)生臟讀問題。
• REPEATABLE READ隔離級(jí)別下，可能發(fā)生幻讀問題，但是不可以發(fā)生臟讀和不可重復(fù)讀的問題。
• SERIALIZABLE隔離級(jí)別下，各種問題都不可以發(fā)生。

Q2: 臟寫是怎么回事兒？怎么里邊都沒寫呢？
W2: 這是因?yàn)榕K寫這個(gè)問題太嚴(yán)重了，不論是哪種隔離級(jí)別，都不允許臟寫的情況發(fā)生。

2.3 MySQL中支持的四種隔離級(jí)別

不同的數(shù)據(jù)庫(kù)廠商對(duì)SQL標(biāo)準(zhǔn)中規(guī)定的四種隔離級(jí)別支持不一樣，比方說Oracle就只支持READ COMMITTED和SERIALIZABLE隔離級(jí)別。MySQL雖然支持4種隔離級(jí)別，但與SQL標(biāo)準(zhǔn)中所規(guī)定的各級(jí)隔離級(jí)別允許發(fā)生的問題卻有些出入，MySQL在REPEATABLE READ隔離級(jí)別下，是可以禁止幻讀問題的發(fā)生的。

MySQL的默認(rèn)隔離級(jí)別為REPEATABLE READ，我們可以手動(dòng)修改一下事務(wù)的隔離級(jí)別。

如何設(shè)置事務(wù)的隔離級(jí)別

我們可以通過下邊的語(yǔ)句修改事務(wù)的隔離級(jí)別：

SET [GLOBAL|SESSION|PERSIST] TRANSACTION ISOLATION LEVEL level;

其中的level可選值有4個(gè)：

level: {
     REPEATABLE READ
   | READ COMMITTED
   | READ UNCOMMITTED
   | SERIALIZABLE
}

設(shè)置事務(wù)的隔離級(jí)別的語(yǔ)句中，在SET關(guān)鍵字后可以放置GLOBAL關(guān)鍵字、SESSION關(guān)鍵字、PERSIST關(guān)鍵字或者什么都不放，這樣會(huì)對(duì)不同范圍的事務(wù)產(chǎn)生不同的影響，具體如下：

• 使用GLOBAL關(guān)鍵字（在全局范圍影響）：

比如：
SET GLOBAL TRANSACTION ISOLATION LEVEL SERIALIZABLE;

則：

• 則：

  • 只對(duì)執(zhí)行完該語(yǔ)句之后產(chǎn)生的會(huì)話起作用。
  • 當(dāng)前已經(jīng)存在的會(huì)話無(wú)效
  • 重啟之后會(huì)恢復(fù)到默認(rèn)值

• 使用SESSION關(guān)鍵字（在會(huì)話范圍影響）：

  比如：
  SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE;

  則：

  • 對(duì)當(dāng)前會(huì)話的所有后續(xù)的事務(wù)有效
  • 該語(yǔ)句可以在已經(jīng)開啟的事務(wù)中間執(zhí)行，但不會(huì)影響當(dāng)前正在執(zhí)行的事務(wù)
  • 如果在事務(wù)之間執(zhí)行，則對(duì)后續(xù)的事務(wù)有效
  • 重啟之后會(huì)恢復(fù)到默認(rèn)值

• 使用PERSIST關(guān)鍵字（使全局系統(tǒng)變量變?yōu)橛谰眯裕?/p>

比如：
SET PERSIST TRANSACTION ISOLATION LEVEL SERIALIZABLE;則：

• 只對(duì)執(zhí)行完該語(yǔ)句之后產(chǎn)生的會(huì)話起作用
• 當(dāng)前已經(jīng)存在的會(huì)話無(wú)效
• 重啟之后不會(huì)恢復(fù)到默認(rèn)值

 小提示：在5.7版本以前在修改全局變量時(shí)候，并不會(huì)影響到配置文件，重啟之后就會(huì)恢復(fù)到默認(rèn)值，MySQL8可以使用PERSIST使全局系統(tǒng)變量變?yōu)橛谰眯?/p>

上述三個(gè)關(guān)鍵字都不用（只對(duì)執(zhí)行語(yǔ)句后的下一個(gè)事務(wù)產(chǎn)生影響）：

比如：SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;

則：

• 只對(duì)當(dāng)前會(huì)話中下一個(gè)即將開啟的事務(wù)有效。
• 下一個(gè)事務(wù)執(zhí)行完后，后續(xù)事務(wù)將恢復(fù)到之前的隔離級(jí)別。
• 該語(yǔ)句不能在已經(jīng)開啟的事務(wù)中間執(zhí)行，會(huì)報(bào)錯(cuò)的

想要查看當(dāng)前會(huì)話默認(rèn)的隔離級(jí)別可以通過查看系統(tǒng)變量transaction_isolation的值來確定：

mysql> SHOW VARIABLES LIKE 'transaction_isolation';
+-----------------------+--------------+
| Variable_name         | Value        |
+-----------------------+--------------+
| transaction_isolation | SERIALIZABLE |
+-----------------------+--------------+
1 row in set (0.01 sec)

或者使用更簡(jiǎn)便的寫法：

mysql> SELECT @@transaction_isolation;
+-------------------------+
| @@transaction_isolation |
+-------------------------+
| SERIALIZABLE            |
+-------------------------+
1 row in set (0.00 sec)

三、MVCC

3.1 版本鏈

我們前邊說過，對(duì)于使用InnoDB存儲(chǔ)引擎的表來說，它的聚簇索引記錄中都包含兩個(gè)必要的隱藏列（row_id并不是必要的，我們創(chuàng)建的表中有主鍵或者非NULL的UNIQUE鍵時(shí)都不會(huì)包含row_id列）：

• trx_id：每次一個(gè)事務(wù)對(duì)某條聚簇索引記錄進(jìn)行改動(dòng)時(shí)，都會(huì)把該事務(wù)的事務(wù)id賦值給trx_id隱藏列。
• roll_pointer：每次對(duì)某條聚簇索引記錄進(jìn)行改動(dòng)時(shí)，都會(huì)把舊的版本寫入到undo日志中，然后這個(gè)隱藏列就相當(dāng)于一個(gè)指針，可以通過它來找到該記錄修改前的信息

比如我們的表hero現(xiàn)在只包含一條記錄：

mysql> SELECT * FROM hero;
+--------+--------+---------+
| number | name   | country |
+--------+--------+---------+
|      1 | 張角   | 東漢    |
+--------+--------+---------+
1 row in set (0.00 sec)

假設(shè)插入該記錄的事務(wù)id為80，那么此刻該條記錄的示意圖如下所示：

小提示：
實(shí)際上insert undo只在事務(wù)回滾時(shí)起作用，當(dāng)事務(wù)提交后，該類型的undo日志就沒用了，它占用的Undo Log Segment也會(huì)被系統(tǒng)回收（也就是該undo日志占用的Undo頁(yè)面鏈表要么被重用，要么被釋放）。雖然真正的insert undo日志占用的存儲(chǔ)空間被釋放了，但是roll_pointer的值并不會(huì)被清除，roll_pointer屬性占用7個(gè)字節(jié)，第一個(gè)比特位就標(biāo)記著它指向的undo日志的類型，如果該比特位的值為1時(shí)，就代表著它指向的undo日志類型為insert undo。所以我們之后在畫圖時(shí)都會(huì)把insert undo給去掉，大家留意一下就好了。

假設(shè)之后兩個(gè)事務(wù)id分別為100、200的事務(wù)對(duì)這條記錄進(jìn)行UPDATE操作，操作流程如下：

小提示：
能不能在兩個(gè)事務(wù)中交叉更新同一條記錄呢？哈哈，這不就是一個(gè)事務(wù)修改了另一個(gè)未提交事務(wù)修改過的數(shù)據(jù)，淪為了臟寫了么？InnoDB使用鎖來保證不會(huì)有臟寫情況的發(fā)生，也就是在第一個(gè)事務(wù)更新了某條記錄后，就會(huì)給這條記錄加鎖，另一個(gè)事務(wù)再次更新時(shí)就需要等待第一個(gè)事務(wù)提交了，把鎖釋放之后才可以繼續(xù)更新。關(guān)于鎖的更多細(xì)節(jié)我們后續(xù)的文章中再進(jìn)行學(xué)習(xí)～

每次對(duì)記錄進(jìn)行更新，都會(huì)記錄一條undo日志，每條undo日志也都有一個(gè)roll_pointer屬性（INSERT操作對(duì)應(yīng)的undo日志沒有該屬性，因?yàn)樵撚涗洸]有更早的版本），可以將這些undo日志都連起來，串成一個(gè)鏈表，所以現(xiàn)在的情況就像下圖一樣：

對(duì)該記錄每次更新后，都會(huì)將舊值放到一條undo日志中，就算是該記錄的一個(gè)舊版本，隨著更新次數(shù)的增多，所有的版本都會(huì)被roll_pointer屬性連接成一個(gè)鏈表，我們把這個(gè)鏈表稱之為版本鏈，版本鏈的頭節(jié)點(diǎn)就是當(dāng)前記錄最新的值。另外，每個(gè)版本中還包含生成該版本時(shí)對(duì)應(yīng)的事務(wù)id，這個(gè)信息很重要，我們稍后就會(huì)用到。

3.2 ReadView

對(duì)于使用READ UNCOMMITTED隔離級(jí)別的事務(wù)來說，由于可以讀到未提交事務(wù)修改過的記錄，所以直接讀取記錄的最新版本就好了；對(duì)于使用SERIALIZABLE隔離級(jí)別的事務(wù)來說，InnoDB的規(guī)定使用加鎖的方式來訪問記錄（加鎖是啥我們后續(xù)文章中說哈）；對(duì)于使用READ COMMITTED和REPEATABLE READ隔離級(jí)別的事務(wù)來說，都必須保證讀到已經(jīng)提交了的事務(wù)修改過的記錄，也就是說假如另一個(gè)事務(wù)已經(jīng)修改了記錄但是尚未提交，是不能直接讀取最新版本的記錄的，核心問題就是：需要判斷一下版本鏈中的哪個(gè)版本是當(dāng)前事務(wù)可見的。為此，InnoDB提出了一個(gè)ReadView的概念，這個(gè)ReadView中主要包含4個(gè)比較重要的內(nèi)容：

• m_ids：表示在生成ReadView時(shí)當(dāng)前系統(tǒng)中活躍的讀寫事務(wù)的事務(wù)id列表。

• min_trx_id：表示在生成ReadView時(shí)當(dāng)前系統(tǒng)中活躍的讀寫事務(wù)中最小的事務(wù)id，也就是m_ids中的最小值。

• max_trx_id：表示生成ReadView時(shí)系統(tǒng)中應(yīng)該分配給下一個(gè)事務(wù)的id值。

• 小提示：
  注意max_trx_id并不是m_ids中的最大值，事務(wù)id是遞增分配的。比方說現(xiàn)在有id為1，2，3這三個(gè)事務(wù)，之后id為3的事務(wù)提交了。那么一個(gè)新的讀事務(wù)在生成ReadView時(shí)，m_ids就包括1和2，min_trx_id的值就是1，max_trx_id的值就是4。

• creator_trx_id：表示生成該ReadView的事務(wù)的事務(wù)id。

  小提示：
  我們前邊說過，只有在對(duì)表中的記錄做改動(dòng)時(shí)（執(zhí)行INSERT、DELETE、UPDATE這些語(yǔ)句時(shí)）才會(huì)為事務(wù)分配事務(wù)id，否則在一個(gè)只讀事務(wù)中的事務(wù)id值都默認(rèn)為0。

有了這個(gè)ReadView，這樣在訪問某條記錄時(shí)，只需要按照下邊的步驟判斷記錄的某個(gè)版本是否可見：

• 如果被訪問版本的trx_id屬性值與ReadView中的creator_trx_id值相同，意味著當(dāng)前事務(wù)在訪問它自己修改過的記錄，所以該版本可以被當(dāng)前事務(wù)訪問。

• 如果被訪問版本的trx_id屬性值小于ReadView中的min_trx_id值，表明生成該版本的事務(wù)在當(dāng)前事務(wù)生成ReadView前已經(jīng)提交，所以該版本可以被當(dāng)前事務(wù)訪問。

• 如果被訪問版本的trx_id屬性值大于或等于ReadView中的max_trx_id值，表明生成該版本的事務(wù)在當(dāng)前事務(wù)生成ReadView后才開啟，所以該版本不可以被當(dāng)前事務(wù)訪問。

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

如果某個(gè)版本的數(shù)據(jù)對(duì)當(dāng)前事務(wù)不可見的話，那就順著版本鏈找到下一個(gè)版本的數(shù)據(jù)，繼續(xù)按照上邊的步驟判斷可見性，依此類推，直到版本鏈中的最后一個(gè)版本。如果最后一個(gè)版本也不可見的話，那么就意味著該條記錄對(duì)該事務(wù)完全不可見，查詢結(jié)果就不包含該記錄。

在MySQL中，READ COMMITTED和REPEATABLE READ隔離級(jí)別的的一個(gè)非常大的區(qū)別就是它們生成ReadView的時(shí)機(jī)不同。我們還是以表hero為例來，假設(shè)現(xiàn)在表hero中只有一條由事務(wù)id為80的事務(wù)插入的一條記錄：

mysql> SELECT * FROM hero;
+--------+--------+---------+
| number | name   | country |
+--------+--------+---------+
|      1 | 張角   | 東漢    |
+--------+--------+---------+
1 row in set (0.00 sec)

下來看一下READ COMMITTED和REPEATABLE READ所謂的生成ReadView的時(shí)機(jī)不同到底不同在哪里

3.2.1 READ COMMITTED

對(duì)于使用REPEATABLE COMMITTED隔離級(jí)別的事務(wù)來說，每次讀取數(shù)據(jù)前都生成一個(gè)ReadView。比方說現(xiàn)在系統(tǒng)里有兩個(gè)事務(wù)id分別為100、200的事務(wù)在執(zhí)行：

# Transaction 100
BEGIN;
UPDATE hero SET name = '趙云' WHERE number = 1;
UPDATE hero SET name = '法正' WHERE number = 1;

# Transaction 200
BEGIN;
# 更新了一些別的表的記錄
...

小提示：
再次強(qiáng)調(diào)一遍，事務(wù)執(zhí)行過程中，只有在第一次真正修改記錄時(shí)（比如使用INSERT、DELETE、UPDATE語(yǔ)句），才會(huì)被分配一個(gè)單獨(dú)的事務(wù)id，這個(gè)事務(wù)id是遞增的。所以我們才在Transaction 200中更新一些別的表的記錄，目的是讓它分配事務(wù)id。

此刻，表hero中number為1的記錄得到的版本鏈表如下所示：

假設(shè)現(xiàn)在有一個(gè)使用READ COMMITTED隔離級(jí)別的事務(wù)開始執(zhí)行：

# 使用READ COMMITTED隔離級(jí)別的事務(wù)
BEGIN;
# SELECT1：Transaction 100、200未提交
SELECT * FROM hero WHERE number = 1; # 得到的列name的值為'張角'

這個(gè)SELECT1的執(zhí)行過程如下：

• 在執(zhí)行SELECT語(yǔ)句時(shí)會(huì)先生成一個(gè)ReadView，ReadView的m_ids列表的內(nèi)容就是[100, 200]，min_trx_id為100，max_trx_id為201，creator_trx_id為0。

• 然后從版本鏈中挑選可見的記錄，從圖中可以看出，最新版本的列name的內(nèi)容是'法正'，該版本的trx_id值為100，在m_ids列表內(nèi)，所以不符合可見性要求，根據(jù)roll_pointer跳到下一個(gè)版本。

• 下一個(gè)版本的列name的內(nèi)容是'趙云'，該版本的trx_id值也為100，也在m_ids列表內(nèi)，所以也不符合要求，繼續(xù)跳到下一個(gè)版本。

  下一個(gè)版本的列name的內(nèi)容是'張角'，該版本的trx_id值為80，小于ReadView中的min_trx_id值100，所以這個(gè)版本是符合要求的，最后返回給用戶的版本就是這條列name為'張角'的記錄。

# Transaction 100
BEGIN;
UPDATE hero SET name = '趙云' WHERE number = 1;
UPDATE hero SET name = '法正' WHERE number = 1;
COMMIT;

然后再到事務(wù)id為200的事務(wù)中更新一下表hero中number為1的記錄：

# Transaction 200
BEGIN;
# 更新了一些別的表的記錄
UPDATE hero SET name = '孫尚香' WHERE number = 1;
UPDATE hero SET name = '妲己' WHERE number = 1;

此刻，表hero中number為1的記錄的版本鏈就長(zhǎng)這樣：

然后再到剛才使用READ COMMITTED隔離級(jí)別的事務(wù)中繼續(xù)查找這個(gè)number為1的記錄，如下：

# 使用READ COMMITTED隔離級(jí)別的事務(wù)
BEGIN;
# SELECT1：Transaction 100、200均未提交
SELECT * FROM hero WHERE number = 1; # 得到的列name的值為'張角'
# SELECT2：Transaction 100提交，Transaction 200未提交
SELECT * FROM hero WHERE number = 1; # 得到的列name的值為'法正'

這個(gè)SELECT2的執(zhí)行過程如下：

• 在執(zhí)行SELECT語(yǔ)句時(shí)會(huì)又會(huì)單獨(dú)生成一個(gè)ReadView，該ReadView的m_ids列表的內(nèi)容就是[200]（事務(wù)id為100的那個(gè)事務(wù)已經(jīng)提交了，所以再次生成快照時(shí)就沒有它了），min_trx_id為200，max_trx_id為201，creator_trx_id為0。

• 然后從版本鏈中挑選可見的記錄，從圖中可以看出，最新版本的列name的內(nèi)容是'妲己'，該版本的trx_id值為200，在m_ids列表內(nèi)，所以不符合可見性要求，根據(jù)roll_pointer跳到下一個(gè)版本。

• 下一個(gè)版本的列name的內(nèi)容是'孫尚香'，該版本的trx_id值為200，也在m_ids列表內(nèi)，所以也不符合要求，繼續(xù)跳到下一個(gè)版本。

• 下一個(gè)版本的列name的內(nèi)容是'法正'，該版本的trx_id值為100，小于ReadView中的min_trx_id值200，所以這個(gè)版本是符合要求的，最后返回給用戶的版本就是這條列name為'法正'的記錄。

以此類推，如果之后事務(wù)id為200的記錄也提交了，再次在使用READ COMMITTED隔離級(jí)別的事務(wù)中查詢表hero中number值為1的記錄時(shí)，得到的結(jié)果就是'妲己'了，具體流程我們就不分析了。總結(jié)一下就是：使用READ COMMITTED隔離級(jí)別的事務(wù)在每次查詢開始時(shí)都會(huì)生成一個(gè)獨(dú)立的ReadView。

3.2.2 REPEATABLE READ

對(duì)于使用REPEATABLE READ隔離級(jí)別的事務(wù)來說，只會(huì)在第一次執(zhí)行查詢語(yǔ)句時(shí)生成一個(gè)ReadView，之后的查詢就不會(huì)重復(fù)生成了。比方說現(xiàn)在系統(tǒng)里有兩個(gè)事務(wù)id分別為100、200的事務(wù)在執(zhí)行：

# Transaction 100
BEGIN;
UPDATE hero SET name = '趙云' WHERE number = 1;
UPDATE hero SET name = '法正' WHERE number = 1;

# Transaction 200
BEGIN;
# 更新了一些別的表的記錄
...

此刻，表hero中number為1的記錄得到的版本鏈表如下所示：

假設(shè)現(xiàn)在有一個(gè)使用REPEATABLE READ隔離級(jí)別的事務(wù)開始執(zhí)行：

# 使用REPEATABLE READ隔離級(jí)別的事務(wù)
BEGIN;
# SELECT1：Transaction 100、200未提交
SELECT * FROM hero WHERE number = 1; # 得到的列name的值為'張角'

這個(gè)SELECT1的執(zhí)行過程如下：

• 在執(zhí)行SELECT語(yǔ)句時(shí)會(huì)先生成一個(gè)ReadView，ReadView的m_ids列表的內(nèi)容就是[100, 200]，min_trx_id為100，max_trx_id為201，creator_trx_id為0。

• 然后從版本鏈中挑選可見的記錄，從圖中可以看出，最新版本的列name的內(nèi)容是'法正'，該版本的trx_id值為100，在m_ids列表內(nèi)，所以不符合可見性要求，根據(jù)roll_pointer跳到下一個(gè)版本。

• 下一個(gè)版本的列name的內(nèi)容是'趙云'，該版本的trx_id值也為100，也在m_ids列表內(nèi)，所以也不符合要求，繼續(xù)跳到下一個(gè)版本。

• 下一個(gè)版本的列name的內(nèi)容是'張角'，該版本的trx_id值為80，小于ReadView中的min_trx_id值100，所以這個(gè)版本是符合要求的，最后返回給用戶的版本就是這條列name為'張角'的記錄。

之后，我們把事務(wù)id為100的事務(wù)提交一下：

# Transaction 100
BEGIN;
UPDATE hero SET name = '關(guān)羽' WHERE number = 1;
UPDATE hero SET name = '張飛' WHERE number = 1;
COMMIT;

然后再到事務(wù)id為200的事務(wù)中更新一下表hero中number為1的記錄：

# Transaction 200
BEGIN;
# 更新了一些別的表的記錄
...
UPDATE hero SET name = '孫尚香' WHERE number = 1;
UPDATE hero SET name = '妲己' WHERE number = 1;

此刻，表hero中number為1的記錄的版本鏈就長(zhǎng)這樣：

然后再到剛才使用REPEATABLE READ隔離級(jí)別的事務(wù)中繼續(xù)查找這個(gè)number為1的記錄，如下：

# 使用REPEATABLE READ隔離級(jí)別的事務(wù)
BEGIN;
# SELECT1：Transaction 100、200均未提交
SELECT * FROM hero WHERE number = 1; # 得到的列name的值為'張角'
# SELECT2：Transaction 100提交，Transaction 200未提交
SELECT * FROM hero WHERE number = 1; # 得到的列name的值仍為'張角'

這個(gè)SELECT2的執(zhí)行過程如下：

• 因?yàn)楫?dāng)前事務(wù)的隔離級(jí)別為REPEATABLE READ，而之前在執(zhí)行SELECT1時(shí)已經(jīng)生成過ReadView了，所以此時(shí)直接復(fù)用之前的ReadView，之前的ReadView的m_ids列表的內(nèi)容就是[100, 200]，min_trx_id為100，max_trx_id為201，creator_trx_id為0

• 然后從版本鏈中挑選可見的記錄，從圖中可以看出，最新版本的列name的內(nèi)容是'妲己'，該版本的trx_id值為200，在m_ids列表內(nèi)，所以不符合可見性要求，根據(jù)roll_pointer跳到下一個(gè)版本。

• 下一個(gè)版本的列name的內(nèi)容是'孫尚香'，該版本的trx_id值為200，也在m_ids列表內(nèi)，所以也不符合要求，繼續(xù)跳到下一個(gè)版本。

  下一個(gè)版本的列name的內(nèi)容是'法正'，該版本的trx_id值為100，而m_ids列表中是包含值為100的事務(wù)id的，所以該版本也不符合要求，同理下一個(gè)列name的內(nèi)容是'趙云'的版本也不符合要求。繼續(xù)跳到下一個(gè)版本。

• 下一個(gè)版本的列name的內(nèi)容是'張角'，該版本的trx_id值為80，小于ReadView中的min_trx_id值100，所以這個(gè)版本是符合要求的，最后返回給用戶的版本就是這條列‘name’為'張角'的記錄。

也就是說兩次SELECT查詢得到的結(jié)果是重復(fù)的，記錄的列name值都是'張角'，這就是可重復(fù)讀的含義。如果我們之后再把事務(wù)id為200的記錄提交了，然后再到剛才使用REPEATABLE READ隔離級(jí)別的事務(wù)中繼續(xù)查找這個(gè)number為1的記錄，得到的結(jié)果還是'張角'，具體執(zhí)行過程大家可以自己分析一下。

3.3 MVCC小結(jié)

從上邊的描述中我們可以看出來，所謂的MVCC（Multi-Version Concurrency Control ，多版本并發(fā)控制）指的就是在使用READ COMMITTD、REPEATABLE READ這兩種隔離級(jí)別的事務(wù)在執(zhí)行普通的SELECT操作時(shí)訪問記錄的版本鏈的過程，這樣子可以使不同事務(wù)的讀-寫、寫-讀操作并發(fā)執(zhí)行，從而提升系統(tǒng)性能。READ COMMITTD、REPEATABLE READ這兩個(gè)隔離級(jí)別的一個(gè)很大不同就是：生成ReadView的時(shí)機(jī)不同，READ COMMITTD在每一次進(jìn)行普通SELECT操作前都會(huì)生成一個(gè)ReadView，而REPEATABLE READ只在第一次進(jìn)行普通SELECT操作前生成一個(gè)ReadView，之后的查詢操作都重復(fù)使用這個(gè)ReadView就好了。

小提示：
我們之前說執(zhí)行DELETE語(yǔ)句或者更新主鍵的UPDATE語(yǔ)句并不會(huì)立即把對(duì)應(yīng)的記錄完全從頁(yè)面中刪除，而是執(zhí)行一個(gè)所謂的delete mark操作，相當(dāng)于只是對(duì)記錄打上了一個(gè)刪除標(biāo)志位，這主要就是為MVCC服務(wù)的，大家可以對(duì)比上邊舉的例子自己試想一下怎么使用。
另外，所謂的MVCC只是在我們進(jìn)行普通的SEELCT查詢時(shí)才生效，截止到目前我們所見的所有SELECT語(yǔ)句都算是普通的查詢，至于啥是個(gè)不普通的查詢，我們稍后再說哈～

四、關(guān)于purge

大家有沒有發(fā)現(xiàn)兩件事兒：

• 我們說insert undo在事務(wù)提交之后就可以被釋放掉了，而update undo由于還需要支持MVCC，不能立即刪除掉。

  我們?cè)趯W(xué)習(xí)undo日志的時(shí)候，一個(gè)事務(wù)寫的一組undo日志中都有一個(gè)Undo Log Header部分，這個(gè)Undo Log Header中有一個(gè)名為TRX_UNDO_HISTORY_NODE的屬性，表示名為History鏈表的節(jié)點(diǎn)。當(dāng)一個(gè)事務(wù)提交之后，就會(huì)把這個(gè)事務(wù)的執(zhí)行過程產(chǎn)生的這一組Update undo日志插入到History鏈表的頭部

  我們還說過，每個(gè)回滾段都對(duì)應(yīng)一個(gè)名為Rollbcak Segment Header的頁(yè)面，這個(gè)頁(yè)面中有兩個(gè)屬性：

  • TRX_RSEG_HISTORY：表示Histroy鏈表的基節(jié)點(diǎn)

  • TRX_RSEG_HISTORY_SIZE：表示Histroy鏈表占用的頁(yè)面數(shù)量

  也就是說每個(gè)回滾段都有一個(gè)History鏈表，一個(gè)事務(wù)在某個(gè)回滾段中寫入的一組update undo日志在該事物提交之后就會(huì)加入這個(gè)回滾段的History鏈表。系統(tǒng)中存在很多回滾段，這也意味著可能存在很多個(gè)History鏈表。不過加入到History鏈表的update undo日志所占用的存儲(chǔ)空間頁(yè)沒有釋放掉，他們總不能一直存在吧，那得用多大的存儲(chǔ)空間存放這些undo日志。

• 為了支持MVCC，對(duì)于delete mark操作來說，僅僅是在記錄上打一個(gè)刪除標(biāo)記，并沒有真正將它刪除掉。

  大家應(yīng)該還記得，在一組undo日志中的Undo Log Header部分有個(gè)名為TRX_UNDO_DEL_MARKS的屬性，用來標(biāo)記本組的undo日志中是否包含因delete mark操作二產(chǎn)生的日志，這些打了刪除標(biāo)記的記錄也不能一直存在吧？

為了節(jié)約空間，我們應(yīng)該在合適的時(shí)候把update undo日志以及僅僅被標(biāo)記為刪除的記錄徹底刪除，這個(gè)刪除操作就是purge。不過于問題的關(guān)健在于這個(gè)合適的時(shí)候到底是什么時(shí)候？

update undo日志和被標(biāo)記刪除的記錄都是為了支持MVCC而存在的，只要系統(tǒng)中最早產(chǎn)生的ReadView不在訪問它們，它們的使命就此結(jié)束了，就可以丟進(jìn)歷史的垃圾堆里了。一個(gè)ReadView在什么時(shí)候才肯定不會(huì)訪問某個(gè)事物執(zhí)行過程中產(chǎn)生的undo日志呢？其實(shí)，只要我們能保證生成ReadView時(shí)，某個(gè)事物已經(jīng)提交，那么該ReadView肯定就不需要訪問事物運(yùn)行過程中產(chǎn)生的undo日志了（因?yàn)樵撌挛锼膭?dòng)的最新版均對(duì)該ReadView可見）。

InnoDB為此做了兩件事：

• 在一個(gè)事務(wù)提交時(shí)，會(huì)為這個(gè)事務(wù)生成一個(gè)名為事務(wù)no的值，該值用來表示事務(wù)提交的順序。先提交的事務(wù)的事務(wù)no值小，后提交的事務(wù)的事務(wù)no值大。

  別忘看在一組undo日志中對(duì)應(yīng)的Undo Log Header部分有一個(gè)名為TRX_UNDO_TRX_NO的屬性。當(dāng)事務(wù)提交時(shí)，就把該事物對(duì)應(yīng)的事務(wù)no值填到這個(gè)屬性中，因?yàn)?code>事務(wù)no代表著各個(gè)事務(wù)提交的順序，而History鏈表又是按照事務(wù)提交的順序來排列各種undo日志，所以History鏈表中各組的undo日志也是按照對(duì)應(yīng)的事務(wù)no來排序的。

• 一個(gè)ReadView結(jié)構(gòu)除了包含前面學(xué)習(xí)的幾個(gè)屬性之外，還會(huì)包含一個(gè)事務(wù)no的屬性。在生成一個(gè)ReadView時(shí)，會(huì)把比當(dāng)前系統(tǒng)中最大的事務(wù)no的值還大1的值賦予這個(gè)屬性。

InnoDB還把當(dāng)前系統(tǒng)中所有的ReadView按照創(chuàng)建時(shí)間連成了一個(gè)鏈表。當(dāng)執(zhí)行purge操作時(shí)（這個(gè)purge操作是在專門的后線程中執(zhí)行的），就把系統(tǒng)中最早生成的ReadView給取出來。如果當(dāng)前系統(tǒng)中不存在ReadView,那就現(xiàn)場(chǎng)創(chuàng)建一個(gè)（新創(chuàng)建的這個(gè)ReadView的事務(wù)no值肯定比當(dāng)前已經(jīng)提交的事務(wù)的事務(wù)no值大）。然后從各個(gè)回滾段的History鏈表中取出事務(wù)no值較小的各組undo日志。如果第一組undo日志的事務(wù)no小于當(dāng)前系統(tǒng)最早生成的ReadView的事務(wù)no，就意味著該組undo日志沒有用了，就會(huì)從History鏈表中移除，并且釋放掉它們占用的存儲(chǔ)空間。如果該組undo日志包含因delete mark操作而產(chǎn)生的undo日志（TRX_UNDO_DEL_MARKS的屬性值為1），那么也需要將對(duì)應(yīng)的標(biāo)記為刪除的記錄給徹底刪除。

這里我們需要注意的一點(diǎn)，當(dāng)前系統(tǒng)中系統(tǒng)最早生成的ReadView決定了purge操作中可以清理哪些update undo日志以及打了刪除標(biāo)記的記錄。如果某個(gè)事物使用的REPEATABLE READ隔離級(jí)別，那么該事物一直復(fù)用最初產(chǎn)生的ReadView。假如這個(gè)事務(wù)運(yùn)行了很久，一直沒有提交，那么最早產(chǎn)生的ReadView會(huì)一直不釋放。系統(tǒng)中updtae undo日志和打了刪除標(biāo)記的記錄就會(huì)越來越多，表空間對(duì)應(yīng)的文件也會(huì)越來越大，一條記錄的版本鏈將越來越長(zhǎng)，從而影響系統(tǒng)的性能。

五、總結(jié)

• 并發(fā)的事務(wù)在運(yùn)行過程中會(huì)出現(xiàn)一些可能引發(fā)一致性問題的現(xiàn)象，具體如下:

  • 臟寫：一個(gè)事務(wù)修改了另一個(gè)未提交事務(wù)修改過的數(shù)據(jù)
  • 臟讀：一個(gè)事務(wù)讀到了另一個(gè)未提交事務(wù)修改過的數(shù)據(jù)
  • 不可重復(fù)讀：一個(gè)事務(wù)修改了另一個(gè)未提交事務(wù)讀取的數(shù)據(jù)
  • 幻讀：一個(gè)事務(wù)先根據(jù)某些搜索條件查詢出一些記錄，在該事務(wù)未提交時(shí)，另一個(gè)事務(wù)寫入了一些符合那些搜索條件的記錄

• SOL標(biāo)準(zhǔn)中的4種隔離級(jí)別：

  • READ UNCOMMITTED：可能發(fā)生臟讀、不可重復(fù)讀和幻讀現(xiàn)象

  • READCOMMITTED：可能發(fā)生不可重復(fù)讀和幻讀現(xiàn)象，但是不可能發(fā)生臟讀現(xiàn)象。

  • REPEATABLE READ：可能發(fā)生幻讀現(xiàn)象，但是不可能發(fā)生臟讀和不可重復(fù)讀的現(xiàn)象

  • SERIALIZABLE：各種現(xiàn)象都不可以發(fā)生。

  實(shí)際上，MySOL在REPEATABLE READ隔離級(jí)別下是可以在很大程度上禁止出現(xiàn)幻讀現(xiàn)象的。

• 下面的語(yǔ)句用來設(shè)置事務(wù)的隔離級(jí)別:
  SET [GLOBALI|SESSION|PERSIST] TRANSACTION ISOLATION LEVEL Level;

• 聚簇索引記錄和undo日志中的roll pointer屬性可以串連成一個(gè)記錄的版本鏈

• 通過生成ReadView來判斷記錄的某個(gè)版本的可見性，其中READ COMMITTD在每一次進(jìn)行普通SELECT操作前都會(huì)生成一個(gè)ReadView，而REPEATABLE READ只在第一次進(jìn)行普通SELECT操作前生成一個(gè)ReadView，之后的查詢操作都重復(fù)使用這個(gè)ReadView

• 當(dāng)前系統(tǒng)中，如果最早生成的 ReadView 不再訪問undo日志以及打了刪除標(biāo)記的記錄則可以通過purge操作將它們清除。

以上就是一文帶你了解MySQL之事務(wù)隔離級(jí)別和MVCC的詳細(xì)內(nèi)容，更多關(guān)于MySQL 事務(wù)隔離級(jí)別和MVCC的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論