這是我的錢包，共有 100 萬元。

今天我心情好，我決定給你的轉(zhuǎn)賬 100 萬，最后的結(jié)果肯定是我的余額變?yōu)?0 元，你的余額多了 100 萬元，是不是想到就很開心？轉(zhuǎn)賬這一動作在程序里會涉及到一系列的操作，假設(shè)我向你轉(zhuǎn)賬 100 萬的過程是有下面這幾個步驟組成的：

可以看到這個轉(zhuǎn)賬的過程涉及到了兩次修改數(shù)據(jù)庫的操作。假設(shè)在執(zhí)行第三步驟之后，服務(wù)器忽然掉電了，就會發(fā)生一個蛋疼的事情，我的賬戶扣了 100 萬，但是錢并沒有到你的賬戶上，也就是說這 100 萬消失了！要解決這個問題，就要保證轉(zhuǎn)賬業(yè)務(wù)里的所有數(shù)據(jù)庫的操作是不可分割的，要么全部執(zhí)行成功 ，要么全部失敗，不允許出現(xiàn)中間狀態(tài)的數(shù)據(jù)。數(shù)據(jù)庫中的「事務(wù)（Transaction）」就能達到這樣的效果，我們在轉(zhuǎn)賬操作前先開啟事務(wù)，等所有數(shù)據(jù)庫操作執(zhí)行完成后，才提交事務(wù)，對于已經(jīng)提交的事務(wù)來說，該事務(wù)對數(shù)據(jù)庫所做的修改將永久生效，如果中途發(fā)生發(fā)生中斷或錯誤，那么該事務(wù)期間對數(shù)據(jù)庫所做的修改將會被回滾到?jīng)]執(zhí)行該事務(wù)之前的狀態(tài)。沒錯，今天就來圖解 MySQL 事務(wù)啦，開車！

事務(wù)有哪些特性？

事務(wù)是由 MySQL 的引擎來實現(xiàn)的，我們常見的 InnoDB 引擎它是支持事務(wù)的。不過并不是所有的引擎都能支持事務(wù)，比如 MySQL 原生的 MyISAM 引擎就不支持事務(wù)，也正是這樣，所以大多數(shù) MySQL 的引擎都是用 InnoDB。事務(wù)看起來感覺簡單，但是要實現(xiàn)事務(wù)必須要遵守 4 個特性，分別如下：

• 原子性（Atomicity）：一個事務(wù)中的所有操作，要么全部完成，要么全部不完成，不會結(jié)束在中間某個環(huán)節(jié)，而且事務(wù)在執(zhí)行過程中發(fā)生錯誤，會被回滾到事務(wù)開始前的狀態(tài)，就像這個事務(wù)從來沒有執(zhí)行過一樣；

• 一致性（Consistency）：數(shù)據(jù)庫的完整性不會因為事務(wù)的執(zhí)行而受到破壞，比如表中有一個字段為姓名，它有唯一約束，也就是表中姓名不能重復(fù)，如果一個事務(wù)對姓名字段進行了修改，但是在事務(wù)提交后，表中的姓名變得非唯一性了，這就破壞了事務(wù)的一致性要求，這時數(shù)據(jù)庫就要撤銷該事務(wù)，返回初始化的狀態(tài)。

• 隔離性（Isolation）：數(shù)據(jù)庫允許多個并發(fā)事務(wù)同時對其數(shù)據(jù)進行讀寫和修改的能力，隔離性可以防止多個事務(wù)并發(fā)執(zhí)行時由于交叉執(zhí)行而導(dǎo)致數(shù)據(jù)的不一致。

• 持久性（Durability）：事務(wù)處理結(jié)束后，對數(shù)據(jù)的修改就是永久的，即便系統(tǒng)故障也不會丟失。

InnoDB 引擎通過什么技術(shù)來保證事務(wù)的這四個特性的呢？

• 原子性和持久性是通過 redo log （重做日志）來保證的；

• 一致性是通過 undo log（回滾日志） 來保證的；

• 隔離性是通過 MVCC（多版本并發(fā)控制） 或鎖機制來保證的；?

這次將重點介紹事務(wù)的隔離性，這也是面試時最常問的知識的點。為什么事務(wù)要有隔離性，我們就要知道并發(fā)事務(wù)時會引發(fā)什么問題。

并行事務(wù)會引發(fā)什么問題？

MySQL 服務(wù)端是允許多個客戶端連接的，這意味著 MySQL 會出現(xiàn)同時處理多個事務(wù)的情況。那么在同時處理多個事務(wù)的時候，就可能出現(xiàn)臟讀（dirty read）、不可重復(fù)讀（non-repeatable read）、幻讀（phantom read）的問題。接下來，通過舉例子給大家說明，這些問題是如何發(fā)生的。

臟讀

如果一個事務(wù)「讀到」了另一個「未提交事務(wù)修改過的數(shù)據(jù)」，就意味著發(fā)生了「臟讀」現(xiàn)象。舉個栗子。假設(shè)有 A 和 B 這兩個事務(wù)同時在處理，事務(wù) A 先開始從數(shù)據(jù)庫中讀取小林的余額數(shù)據(jù)，然后再執(zhí)行更新操作，如果此時事務(wù) A 還沒有提交事務(wù)，而此時正好事務(wù) B 也從數(shù)據(jù)庫中讀取小林的余額數(shù)據(jù)，那么事務(wù) B 讀取到的余額數(shù)據(jù)是剛才事務(wù) A 更新后的數(shù)據(jù)，即使沒有提交事務(wù)。

因為事務(wù) A 是還沒提交事務(wù)的，也就是它隨時可能發(fā)生回滾操作，如果在上面這種情況事務(wù) A 發(fā)生了回滾，那么事務(wù) B 剛才得到的數(shù)據(jù)就是過期的數(shù)據(jù)，這種現(xiàn)象就被稱為臟讀。

不可重復(fù)讀

在一個事務(wù)內(nèi)多次讀取同一個數(shù)據(jù)，如果出現(xiàn)前后兩次讀到的數(shù)據(jù)不一樣的情況，就意味著發(fā)生了「不可重復(fù)讀」現(xiàn)象。舉個栗子。假設(shè)有 A 和 B 這兩個事務(wù)同時在處理，事務(wù) A 先開始從數(shù)據(jù)庫中讀取小林的余額數(shù)據(jù)，然后繼續(xù)執(zhí)行代碼邏輯處理，在這過程中如果事務(wù) B 更新了這條數(shù)據(jù)，并提交了事務(wù)，那么當(dāng)事務(wù) A 再次讀取該數(shù)據(jù)時，就會發(fā)現(xiàn)前后兩次讀到的數(shù)據(jù)是不一致的，這種現(xiàn)象就被稱為不可重復(fù)讀。

幻讀

在一個事務(wù)內(nèi)多次查詢某個符合查詢條件的「記錄數(shù)量」，如果出現(xiàn)前后兩次查詢到的記錄數(shù)量不一樣的情況，就意味著發(fā)生了「幻讀」現(xiàn)象。舉個栗子。假設(shè)有 A 和 B 這兩個事務(wù)同時在處理，事務(wù) A 先開始從數(shù)據(jù)庫查詢賬戶余額大于 100 萬的記錄，發(fā)現(xiàn)共有 5 條，然后事務(wù) B 也按相同的搜索條件也是查詢出了 5 條記錄。

接下來，事務(wù) A 插入了一條余額超過 100 萬的賬號，并提交了事務(wù)，此時數(shù)據(jù)庫超過 100 萬余額的賬號個數(shù)就變?yōu)?6。然后事務(wù) B 再次查詢賬戶余額大于 100 萬的記錄，此時查詢到的記錄數(shù)量有 6 條，發(fā)現(xiàn)和前一次讀到的記錄數(shù)量不一樣了，就感覺發(fā)生了幻覺一樣，這種現(xiàn)象就被稱為幻讀。

事務(wù)的隔離級別有哪些？

前面我們提到，當(dāng)多個事務(wù)并發(fā)執(zhí)行時可能會遇到「臟讀、不可重復(fù)讀、幻讀」的現(xiàn)象，這些現(xiàn)象會對事務(wù)的一致性產(chǎn)生不同程序的影響。

• 臟讀：讀到其他事務(wù)未提交的數(shù)據(jù)；

• 不可重復(fù)讀：前后讀取的數(shù)據(jù)不一致；?

• 幻讀：前后讀取的記錄數(shù)量不一致。

這三個現(xiàn)象的嚴重性排序如下：

SQL 標(biāo)準(zhǔn)提出了四種隔離級別來規(guī)避這些現(xiàn)象，隔離級別約高，性能效率就越低，這四個隔離級別如下：

• 讀未提交（read uncommitted），指一個事務(wù)還沒提交時，它做的變更就能被其他事務(wù)看到；

• 讀提交（read committed），指一個事務(wù)提交之后，它做的變更才能被其他事務(wù)看到；

• 可重復(fù)讀（repeatable read），指一個事務(wù)執(zhí)行過程中看到的數(shù)據(jù)，一直跟這個事務(wù)啟動時看到的數(shù)據(jù)是一致的，MySQL InnoDB 引擎的默認隔離級別；

• 串行化（serializable?）；會對記錄加上讀寫鎖，在多個事務(wù)對這條記錄進行讀寫操作時，如果發(fā)生了讀寫沖突的時候，后訪問的事務(wù)必須等前一個事務(wù)執(zhí)行完成，才能繼續(xù)執(zhí)行；

按隔離水平高低排序如下：

針對不同的隔離級別，并發(fā)事務(wù)時可能發(fā)生的現(xiàn)象也會不同。

也就是說：

• 在「讀未提交」隔離級別下，可能發(fā)生臟讀、不可重復(fù)讀和幻讀現(xiàn)象；

• 在「讀提交」隔離級別下，可能發(fā)生不可重復(fù)讀和幻讀現(xiàn)象，但是不可能發(fā)生臟讀現(xiàn)象；

• 在「可重復(fù)讀」隔離級別下，可能發(fā)生幻讀現(xiàn)象，但是不可能臟讀和不可重復(fù)讀現(xiàn)象；

• 在「串行化」隔離級別下，臟讀、不可重復(fù)讀和幻讀現(xiàn)象都不可能會發(fā)生。

所以，要解決臟讀現(xiàn)象，就要升級到「讀提交」以上的隔離級別；要解決不可重復(fù)讀現(xiàn)象，就要升級到「可重復(fù)讀」的隔離級別。不過，要解決幻讀現(xiàn)象不建議將隔離級別升級到「串行化」，因為這樣會導(dǎo)致數(shù)據(jù)庫在并發(fā)事務(wù)時性能很差。InnoDB 引擎的默認隔離級別雖然是「可重復(fù)讀」，但是它通過next-key lock 鎖（行鎖和間隙鎖的組合）來鎖住記錄之間的“間隙”和記錄本身，防止其他事務(wù)在這個記錄之間插入新的記錄，這樣就避免了幻讀現(xiàn)象。接下里，舉個具體的例子來說明這四種隔離級別，有一張賬戶余額表，里面有一條記錄：然后有兩個并發(fā)的事務(wù)，事務(wù) A 只負責(zé)查詢余額，事務(wù) B 則會將我的余額改成 200 萬，下面是按照時間順序執(zhí)行兩個事務(wù)的行為：

在不同隔離級別下，事務(wù) A 執(zhí)行過程中查詢到的余額可能會不同：

• 在「讀未提交」隔離級別下，事務(wù) B 修改余額后，雖然沒有提交事務(wù)，但是此時的余額已經(jīng)可以被事務(wù) A 看見了，于是事務(wù) A 中余額 V1 查詢的值是 200 萬，余額 V2、V3 自然也是 200 萬了；

• 在「讀提交」隔離級別下，事務(wù) B 修改余額后，因為沒有提交事務(wù)，所以事務(wù) A 中余額 V1 的值還是 100 萬，等事務(wù) B 提交完后，最新的余額數(shù)據(jù)才能被事務(wù) A 看見，因此額 V2、V3 都是 200 萬；

• 在「可重復(fù)讀」隔離級別下，事務(wù) A 只能看見啟動事務(wù)時的數(shù)據(jù)，所以余額 V1、余額 V2 的值都是 100 萬，當(dāng)事務(wù) A 提交事務(wù)后，就能看見最新的余額數(shù)據(jù)了，所以余額 V3 的值是 200 萬；

• 在「串行化」隔離級別下，事務(wù) B 在執(zhí)行將余額 100 萬修改為 200 萬時，由于此前事務(wù) A 執(zhí)行了讀操作，這樣就發(fā)生了讀寫沖突，于是就會被鎖住，直到事務(wù) A 提交后，事務(wù) B 才可以繼續(xù)執(zhí)行，所以從 A 的角度看，余額 V1、V2 的值是 100 萬，余額 V3 的值是 200萬。

這四種隔離級別具體是如何實現(xiàn)的呢？

• 對于「讀未提交」隔離級別的事務(wù)來說，因為可以讀到未提交事務(wù)修改的數(shù)據(jù)，所以直接讀取最新的數(shù)據(jù)就好了；

• 對于「串行化」隔離級別的事務(wù)來說，通過加讀寫鎖的方式來避免并行訪問；

• 對于「讀提交」和「可重復(fù)讀」隔離級別的事務(wù)來說，它們是通過 **Read View **來實現(xiàn)的，它們的區(qū)別在于創(chuàng)建 Read View 的時機不同，大家可以把 Read View 理解成一個數(shù)據(jù)快照，就像相機拍照那樣，定格某一時刻的風(fēng)景。「讀提交」隔離級別是在每個讀取數(shù)據(jù)前都生成一個 Read View，而「可重復(fù)讀」隔離級別是啟動事務(wù)時生成一個 Read View，然后整個事務(wù)期間都在用這個 Read View。

接下來詳細說下，「讀提交」和「可重復(fù)讀」隔離級別到底怎樣實現(xiàn)的，Read View 又是如何工作的？

可重復(fù)讀隔離級別是如何實現(xiàn)的？

「可重復(fù)讀」隔離級別是啟動事務(wù)時生成一個 Read View，然后整個事務(wù)期間都在用這個 Read View。想要知道可重復(fù)讀隔離級別是如何實現(xiàn)的，我們需要了解兩個知識：

• Read View 中四個字段作用；

• 聚族索引記錄中兩個跟事務(wù)有關(guān)的隱藏列；

那 Read View 到底是個什么東西？

Read View 有四個重要的字段：

• m_ids ：指的是創(chuàng)建 Read View 時當(dāng)前數(shù)據(jù)庫中活躍且未提交的事務(wù)的事務(wù) id 列表，注意是一個列表。

• min_trx_id ：指的是創(chuàng)建 Read View 時當(dāng)前數(shù)據(jù)庫中活躍且未提交的事務(wù)中最小事務(wù)的事務(wù) id，也就是 m_ids 的最小值。

• max_trx_id ：這個并不是 m_ids 的最大值，而是創(chuàng)建 Read View 時當(dāng)前數(shù)據(jù)庫中應(yīng)該給下一個事務(wù)的 id 值；

• creator_trx_id ：指的是創(chuàng)建該 Read View 的事務(wù)的事務(wù) id。

知道了 Read View 的字段，我們還需要了解聚族索引記錄中的兩個隱藏列，假設(shè)在賬戶余額表插入一條小林余額為 100 萬的記錄，然后我把這兩個隱藏列也畫出來，該記錄的整個示意圖如下：

對于使用 InnoDB 存儲引擎的數(shù)據(jù)庫表，它的聚族索引記錄中都包含下面兩個隱藏列：

• trx_id，當(dāng)一個事務(wù)對某條聚族索引記錄進行改動時，就會把該事務(wù)的事務(wù) id 記錄在 trx_id 隱藏列里；

• roll_pointer，每次對某條聚族索引記錄進行改動時，都會把舊版本的記錄寫入到 undo 日志中，然后這個隱藏列是個指針，指向每一個舊版本記錄，于是就可以通過它找到修改前的記錄。

了解完這兩個知識點后，就可以跟大家說說可重復(fù)讀隔離級別是如何實現(xiàn)的。假設(shè)事務(wù) A 和 事務(wù) B 差不多同一時刻啟動，那這兩個事務(wù)創(chuàng)建的 Read View 如下：

事務(wù) A 和 事務(wù) B 的 Read View 具體內(nèi)容如下：

• 在事務(wù) A 的 Read View 中，它的事務(wù) id 是 51，由于與事務(wù) B 同時啟動，所以此時活躍的事務(wù)的事務(wù) id 列表是 51 和 52，活躍的事務(wù) id 中最小的事務(wù) id 是事務(wù) A 本身，下一個事務(wù) id 應(yīng)該是 53。

• 在事務(wù) B 的 Read View 中，它的事務(wù) id 是 52，由于與事務(wù) A 同時啟動，所以此時活躍的事務(wù)的事務(wù) id 列表是 51 和 52，活躍的事務(wù) id 中最小的事務(wù) id 是事務(wù) A，下一個事務(wù) id 應(yīng)該是 53。

然后讓事務(wù) A 去讀賬戶余額為 100 萬的記錄，在找到記錄后，它會先看這條記錄的 trx_id，此時發(fā)現(xiàn) trx_id 為 50，通過和事務(wù) A 的 Read View 的 m_ids 字段發(fā)現(xiàn)，該記錄的事務(wù) id 并不在活躍事務(wù)的列表中，并且小于事務(wù) A 的事務(wù) id，這意味著，這條記錄的事務(wù)早就在事務(wù) A 前提交過了，所以該記錄對事務(wù) A 可見，也就是事務(wù) A 可以獲取到這條記錄。接著，事務(wù) B 通過 update 語句將這條記錄修改了，將小林的余額改成 200 萬，這時 MySQL 會記錄相應(yīng)的 undo log，并以鏈表的方式串聯(lián)起來，形成版本鏈，如下圖：

你可以在上圖的「記錄字段」看到，由于事務(wù) B 修改了該記錄，以前的記錄就變成舊版本記錄了，于是最新記錄和舊版本記錄通過鏈表的方式串起來，而且最新記錄的 trx_id 是事務(wù) B 的事務(wù) id。然后如果事務(wù) A 再次讀取該記錄，發(fā)現(xiàn)這條記錄的 trx_id 為 52，比自己的事務(wù) id 還大，并且比下一個事務(wù) id 53 小，這意味著，事務(wù) A 讀到是和自己同時啟動事務(wù)的事務(wù) B 修改的數(shù)據(jù)，這時事務(wù) A 并不會讀取這條記錄，而是沿著 undo log 鏈條往下找舊版本的記錄，直到找到 trx_id 等于或者小于事務(wù) A 的事務(wù) id 的第一條記錄，所以事務(wù) A 再一次讀取到 trx_id 為 50 的記錄，也就是小林余額是 100 萬的這條記錄?！缚芍貜?fù)讀」隔離級別就是在啟動時創(chuàng)建了 Read View，然后在事務(wù)期間讀取數(shù)據(jù)的時候，在找到數(shù)據(jù)后，先會將該記錄的 trx_id 和該事務(wù)的 Read View 里的字段做個比較：

• 如果記錄的 trx_id 比該事務(wù)的 Read View 中的 creator_trx_id 要小，且不在 m_ids 列表里，這意味著這條記錄的事務(wù)早就在該事務(wù)前提交過了，所以該記錄對該事務(wù)可見；

• 如果記錄的 trx_id 比該事務(wù)的 Read View 中的 creator_trx_id 要大，且在 m_ids 列表里，這意味著該事務(wù)讀到的是和自己同時啟動的另外一個事務(wù)修改的數(shù)據(jù)，這時就不應(yīng)該讀取這條記錄，而是沿著 undo log 鏈條往下找舊版本的記錄，直到找到 trx_id 等于或者小于該事務(wù) id 的第一條記錄。

就是通過這樣的方式實現(xiàn)了，「可重復(fù)讀」隔離級別下在事務(wù)期間讀到的數(shù)據(jù)都是事務(wù)啟動前的記錄。這種通過記錄的版本鏈來控制并發(fā)事務(wù)訪問同一個記錄時的行為，這就叫 MVCC（多版本并發(fā)控制）。

讀提交隔離級別是如何實現(xiàn)的？

「讀提交」隔離級別是在每個 select 都會生成一個新的 Read View，也意味著，事務(wù)期間的多次讀取同一條數(shù)據(jù)，前后兩次讀的數(shù)據(jù)可能會出現(xiàn)不一致，因為可能這期間另外一個事務(wù)修改了該記錄，并提交了事務(wù)。那讀提交隔離級別是怎么實現(xiàn)呢？我們還是以前面的例子來聊聊。假設(shè)事務(wù) A 和 事務(wù) B 差不多同一時刻啟動，然后事務(wù) B 將小林的賬戶余額修改成了 200 萬，但是事務(wù) B 還未提交，這時事務(wù) A 讀到的數(shù)據(jù)，應(yīng)該還是小林賬戶余額為 100 萬的數(shù)據(jù)，那具體怎么做到的呢？

事務(wù) A 在找到小林這條記錄時，會看這條記錄的 trx_id，發(fā)現(xiàn)和事務(wù) A 的 Read View 中的 creator_trx_id 要大，而且還在 m_ids 列表里，說明這條記錄被事務(wù) B 修改過，而且還可以知道事務(wù) B 并沒有提交事務(wù)，因為如果提交了事務(wù)，那么這條記錄的 trx_id 就不會在 m_ids 列表里。因此，事務(wù) A 不能讀取該記錄，而是沿著 undo log 鏈條往下找。當(dāng)事務(wù) B 修改數(shù)據(jù)并提交了事務(wù)后，這時事務(wù) A 讀到的數(shù)據(jù)，就是小林賬戶余額為 200 萬的數(shù)據(jù)，那具體怎么做到的呢？

事務(wù) A 在找到小林這條記錄時，會看這條記錄的 trx_id，發(fā)現(xiàn)和事務(wù) A 的 Read View 中的 creator_trx_id 要大，而且不在 m_ids 列表里，說明該記錄的 trx_id 的事務(wù)是已經(jīng)提交過的了，于是事務(wù) A 就可以讀取這條記錄，這也就是所謂的讀已提交機制。

總結(jié)

事務(wù)是在 MySQL 引擎層實現(xiàn)的，我們常見的 InnoDB 引擎是支持事務(wù)的，事務(wù)的四大特性是原子性、一致性、隔離性、持久性，我們這次主要講的是隔離性。當(dāng)多個事務(wù)并發(fā)執(zhí)行的時候，會引發(fā)臟讀、不可重復(fù)讀、幻讀這些問題，那為了避免這些問題，SQL 提出了四種隔離級別，分別是讀未提交、讀已提交、可重復(fù)讀、串行化，從左往右隔離級別順序遞增，隔離級別越高，意味著性能越差，InnoDB 引擎的默認隔離級別是可重復(fù)讀。要解決臟讀現(xiàn)象，就要將隔離級別升級到讀已提交以上的隔離級別，要解決不可重復(fù)讀現(xiàn)象，就要將隔離級別升級到可重復(fù)讀以上的隔離級別。而對于幻讀現(xiàn)象，不建議將隔離級別升級為串行化，因為這會導(dǎo)致數(shù)據(jù)庫并發(fā)時性能很差。InnoDB 引擎的默認隔離級別雖然是「可重復(fù)讀」，但是它通過next-key lock 鎖（行鎖和間隙鎖的組合）來鎖住記錄之間的“間隙”和記錄本身，防止其他事務(wù)在這個記錄之間插入新的記錄，這樣就避免了幻讀現(xiàn)象。對于「讀提交」和「可重復(fù)讀」隔離級別的事務(wù)來說，它們是通過 **Read View **來實現(xiàn)的，它們的區(qū)別在于創(chuàng)建 Read View 的時機不同：

• 「讀提交」隔離級別是在每個 select 都會生成一個新的 Read View，也意味著，事務(wù)期間的多次讀取同一條數(shù)據(jù)，前后兩次讀的數(shù)據(jù)可能會出現(xiàn)不一致，因為可能這期間另外一個事務(wù)修改了該記錄，并提交了事務(wù)。

• 「可重復(fù)讀」隔離級別是啟動事務(wù)時生成一個 Read View，然后整個事務(wù)期間都在用這個 Read View，這樣就保證了在事務(wù)期間讀到的數(shù)據(jù)都是事務(wù)啟動前的記錄。

這兩個隔離級別實現(xiàn)是通過「事務(wù)的 Read View 里的字段」和「記錄中的兩個隱藏列」的比對，來控制并發(fā)事務(wù)訪問同一個記錄時的行為，這就叫 MVCC（多版本并發(fā)控制）。今天就到這啦。后續(xù)繼續(xù)圖解 MySQL，下次就講 MySQL 各種鎖。爭去早日搞出《圖解 MySQL》PDF。