本篇博客參考掘金小冊(cè)——MySQL 是怎樣運(yùn)行的：從根兒上理解 MySQL
以及極客時(shí)間——MySQL實(shí)戰(zhàn)45講。
雖然我們不是DBA，可能對(duì)數(shù)據(jù)庫(kù)沒(méi)那么了解，但是對(duì)于數(shù)據(jù)庫(kù)中的索引、事務(wù)、鎖，我們還是必須要有一個(gè)較為淺顯的認(rèn)識(shí)，今天我就和大家聊聊事務(wù)。
為什么要有事務(wù)
說(shuō)到事務(wù)，不得不提到轉(zhuǎn)賬的事情，幾乎所有的關(guān)于事務(wù)的文章都會(huì)提到這個(gè)老掉牙的案例，我也不例外。
轉(zhuǎn)賬在數(shù)據(jù)庫(kù)層面可以簡(jiǎn)單的抽象成兩個(gè)部分：
- 從自己的賬戶中扣除轉(zhuǎn)賬金額；
- 往對(duì)方賬戶中增加轉(zhuǎn)賬金額。
如果先從自己的賬戶中扣除轉(zhuǎn)賬金額，再往對(duì)方賬戶中增加轉(zhuǎn)賬金額，扣除執(zhí)行成功，增加執(zhí)行失敗，那自己的賬戶白白少了100塊，欲哭無(wú)淚。
如果先往對(duì)方賬戶中增加轉(zhuǎn)賬金額，再?gòu)淖约旱馁~戶中扣除轉(zhuǎn)賬金額，增加執(zhí)行成功，扣除執(zhí)行失敗，那對(duì)方賬戶白白增加了100塊，自己的賬戶也沒(méi)有扣錢(qián)，喜大普奔。
不管是讓你欲哭無(wú)淚，還是喜大普奔，銀行都不會(huì)容忍這樣的事情發(fā)生，他們會(huì)引入事務(wù)來(lái)解決這類問(wèn)題。
事務(wù)的特性
- 原子性（Atomicity）：事務(wù)包含的所有操作要么全部成功（提交），要么全部失敗（回滾）。
- 一致性（Consistency）：事務(wù)的執(zhí)行的前后數(shù)據(jù)的完整性保持一致。
- 隔離性（Isolation）：一個(gè)事務(wù)執(zhí)行的過(guò)程中，不應(yīng)該受到其他事務(wù)的干擾。
- 持久性（Durability）：事務(wù)一旦結(jié)束，數(shù)據(jù)就持久到數(shù)據(jù)庫(kù)，即使提交后，數(shù)據(jù)庫(kù)發(fā)生崩潰，也不會(huì)丟失提交的數(shù)據(jù)。
四種特性，簡(jiǎn)稱ACID，其中最不好理解的就是一致性，有不少人認(rèn)為原子性、隔離性、持久性就是為了保證一致性，我們也不搞學(xué)術(shù)研究，一致性到底該怎么解釋，到底怎么定義一致性，就看各位看官的了。
事務(wù)的隔離級(jí)別
從某個(gè)角度來(lái)說(shuō)，我們可以控制的、或者說(shuō)需要研究的只有隔離性這一個(gè)特性，而要控制隔離性，幾乎只有調(diào)整隔離級(jí)別這一個(gè)手段，下面我們就來(lái)看看事務(wù)的隔離級(jí)別。
數(shù)據(jù)庫(kù)是一個(gè)客戶端/服務(wù)器架構(gòu)的軟件，每個(gè)客戶端與服務(wù)器連接后，就會(huì)產(chǎn)生一個(gè)session（會(huì)話），客戶端和服務(wù)器的交互就是在session中進(jìn)行的，理論上來(lái)說(shuō)，如果服務(wù)器同時(shí)只能處理一個(gè)事務(wù)，其他的事務(wù)都排隊(duì)等待，當(dāng)該事務(wù)提交后，服務(wù)器才處理下一個(gè)事務(wù)，這樣才真正具有“隔離性”，什么問(wèn)題都沒(méi)有了，但是如果是這樣，性能就太差了，在性能和隔離性之間，只能做一些平衡，所以數(shù)據(jù)庫(kù)提供了好幾個(gè)隔離級(jí)別供我們選擇。
在講隔離級(jí)別之前，我們先來(lái)看看事務(wù)并發(fā)執(zhí)行會(huì)遇到什么問(wèn)題。
為了保證下面的敘述可以順利進(jìn)行，我們要先建一張表：
CREATE TABLE `student` (
`id` int(11) unsigned NOT NULL AUTO_INCREMENT,
`name` varchar(50) DEFAULT NULL COMMENT '姓名',
`age` int(11) DEFAULT NULL COMMENT '年齡',
`grade` int(11) DEFAULT NULL COMMENT '年級(jí)',
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8mb4;
臟寫(xiě)
如圖所示：
- sessionA和sessionB開(kāi)啟了一個(gè)事務(wù)；
- sessionB把id=2的name修改成了“地底王”；
- sessionA把id=2的name修改成了“夢(mèng)境地底王”；
- sessionB回滾了事務(wù)；
- sessionA提交了事務(wù)。
如果sessionB在回滾事務(wù)的時(shí)候把sessionA的修改也給回滾了，導(dǎo)致sessionA的提交丟失了，這種現(xiàn)象就被稱為“臟寫(xiě)”。sessionA會(huì)一臉懵逼，我明明修改了數(shù)據(jù)，也提交了數(shù)據(jù)，為什么數(shù)據(jù)沒(méi)有變化呢。
臟讀
如圖所示：
- sessionA和sessionB開(kāi)啟了一個(gè)事務(wù)；
- sessionB把id=2的name修改成了“地底王”，此時(shí)還未提交；
- sessionA查詢了id=2的數(shù)據(jù)，如果讀出來(lái)的數(shù)據(jù)的name是“地底王”，也就是讀到了sessionB還沒(méi)有提交的數(shù)據(jù)，就被稱為“臟讀”。
不可重復(fù)讀
如圖所示：
- sessionA和sessionB開(kāi)啟了一個(gè)事務(wù)；
- sessionA查詢id=2的數(shù)據(jù)，假如name是“地底王”，
- sessionB把id=2的name修改成了“夢(mèng)境地底王”，隨后提交了事務(wù)；
- sessionA再一次查詢了id=2的數(shù)據(jù)，如果name是“夢(mèng)境地底王”，說(shuō)明在同一個(gè)事務(wù)中，sessionA前后讀到的數(shù)據(jù)不一致，就被稱為“不可重復(fù)讀”。
幻讀
如圖所示：
- sessionA和sessionB開(kāi)啟了一個(gè)事務(wù)；
- sessionA查詢name=“地底王”的數(shù)據(jù)，假設(shè)此時(shí)讀到了一條記錄；
- sessionB又插入一條name=“地底王”的數(shù)據(jù)，隨后提交；
- seesionA再一次查詢name=“地底王”的數(shù)據(jù)，如果此時(shí)讀到了兩條記錄，第二次查詢讀到了第一次查詢未查詢出來(lái)的數(shù)據(jù)，就被稱為“幻讀”。
四種隔離級(jí)別
我們知道了在并發(fā)執(zhí)行事務(wù)的時(shí)候，會(huì)遇到什么問(wèn)題，有些問(wèn)題比較嚴(yán)重，有些問(wèn)題比較輕微，一般來(lái)說(shuō)，我們認(rèn)為按照嚴(yán)重性排序是這樣的：
臟寫(xiě)>臟讀>不可重復(fù)讀>幻讀
在SQL標(biāo)準(zhǔn)定義中，設(shè)定了四種隔離級(jí)別，來(lái)解決上述的問(wèn)題：
- 未提交讀（READ UNCOMMITTED）：
最低的隔離級(jí)別，會(huì)有“臟讀”、“不可重復(fù)讀”，“幻讀”三個(gè)問(wèn)題。 - 讀已提交（READ COMMITTED）：
SQLServer默認(rèn)隔離級(jí)別，可以避免“臟讀”，會(huì)有“不可重復(fù)讀”，“幻讀”兩個(gè)問(wèn)題。 - 可重復(fù)讀（REPEATABLE READ）：
可以避免“臟讀”，“不可重復(fù)讀”兩個(gè)問(wèn)題，會(huì)有“幻讀”問(wèn)題。
MySQL默認(rèn)隔離級(jí)別，但是在MySQL中，此隔離級(jí)別解決了“幻讀”問(wèn)題。 - 串行化（SERIALIZABLE）：
所有的問(wèn)題都不會(huì)發(fā)生。
因?yàn)榕K寫(xiě)的問(wèn)題實(shí)在太嚴(yán)重了，在任何隔離級(jí)別下，都不會(huì)有臟寫(xiě)的問(wèn)題。
MVCC
前面說(shuō)的都是開(kāi)胃菜，相信大部分小伙伴對(duì)于上述內(nèi)容都是手到擒來(lái)，所以我連如何修改事務(wù)隔離級(jí)別都沒(méi)有介紹，各種實(shí)驗(yàn)也都沒(méi)有做，就是要把大量的時(shí)間、文字投入到這一部分內(nèi)容中來(lái)。
MVCC，全稱是Mutil-Version Concurrency Control，翻譯成中文是多版本并發(fā)控制，MySQL就利用了MVCC來(lái)判斷在一個(gè)事務(wù)中，哪個(gè)數(shù)據(jù)可以被讀出來(lái)，哪個(gè)數(shù)據(jù)不能被讀出來(lái)。
多版本
在看MVCC之前，我們有必要知道另外一個(gè)知識(shí)點(diǎn)，數(shù)據(jù)庫(kù)存儲(chǔ)一行行數(shù)據(jù)，是分為兩個(gè)部分來(lái)存儲(chǔ)的，一個(gè)是數(shù)據(jù)行的額外信息（本篇博客不涉及），一個(gè)是真實(shí)的數(shù)據(jù)記錄，MySQL會(huì)為每一行真實(shí)數(shù)據(jù)記錄添加兩三個(gè)隱藏的字段：
- row_id
非必須，如果表中有自定義的主鍵或者有Unique鍵，就不會(huì)添加row_id字段，如果兩者都沒(méi)有，MySQL會(huì)“自作主張”添加row_id字段。 - transaction_id
必須，事務(wù)Id，代表這一行數(shù)據(jù)是由哪個(gè)事務(wù)id創(chuàng)建的。 - roll_pointer
必須，回滾指針，指向這行數(shù)據(jù)的上一個(gè)版本。
如下圖所示：
在這里需要著重說(shuō)明下事務(wù)id，當(dāng)我們開(kāi)啟一個(gè)事務(wù)，并不會(huì)馬上獲得事務(wù)id，哪怕我們?cè)谑聞?wù)中執(zhí)行select語(yǔ)句，也是沒(méi)有事務(wù)id的（事務(wù)id為0），只有執(zhí)行insert/update/delete語(yǔ)句才能獲得事務(wù)id，這一點(diǎn)尤為重要。
其中和MVCC緊密相關(guān)的是transaction_id和roll_pointer兩個(gè)字段，在開(kāi)發(fā)過(guò)程中，我們無(wú)需關(guān)心，但是要研究MVCC，我們必須關(guān)心。
如果有類似這樣的一行數(shù)據(jù)：
代表這行數(shù)據(jù)是由transaction_id為9的事務(wù)創(chuàng)建出來(lái)的，roll_pointer是空的，因?yàn)檫@是一條新紀(jì)錄。
實(shí)際上，roll_pointer并不是空的，如果真要解釋，需要繞一大圈，理解成空的，問(wèn)題也不大。
當(dāng)我們開(kāi)啟事務(wù)，對(duì)這條數(shù)據(jù)進(jìn)行修改，會(huì)變成這樣：
有點(diǎn)感覺(jué)了吧，這就像一個(gè)單向鏈表，稱之為“版本鏈”，最上面的數(shù)據(jù)是這個(gè)數(shù)據(jù)的最新版本，roll_pointer指向這個(gè)數(shù)據(jù)的舊版本，給人的感覺(jué)就是一行數(shù)據(jù)有多個(gè)版本，是不是符合“多版本并發(fā)控制”中的“多版本”這個(gè)概念，
那么“并發(fā)控制”又是怎么做到的呢，別急，繼續(xù)往下看。
ReadView
哎，下面又要引出一個(gè)新的概念：ReadView。
對(duì)于READ UNCOMMITTED來(lái)說(shuō)，可以讀取到其他事務(wù)還沒(méi)有提交的數(shù)據(jù)，所以直接把這個(gè)數(shù)據(jù)的最新版本讀出來(lái)就可以了，對(duì)于SERIALIZABLE來(lái)說(shuō)，是用加鎖的方式來(lái)訪問(wèn)記錄。
剩下的就是READ COMMITTED和REPEATABLE READ，這兩個(gè)事務(wù)隔離級(jí)別都要保證讀到的數(shù)據(jù)是其他事務(wù)已經(jīng)提交的，也就是不能無(wú)腦把一行數(shù)據(jù)的最新版本給讀出來(lái)了，但是這兩個(gè)還是有一定的區(qū)別，最核心的問(wèn)題就在于“我到底可以讀取這個(gè)數(shù)據(jù)的哪個(gè)版本”。
為了解決這個(gè)問(wèn)題，ReadView的概念就出現(xiàn)了，ReadView包含四個(gè)比較重要的內(nèi)容：
- m_ids：表示在生成ReadView時(shí)，系統(tǒng)中活躍的事務(wù)id集合。
- min_trx_id：表示在生成ReadView時(shí)，系統(tǒng)中活躍的最小事務(wù)id，也就是 m_ids中的最小值。
- max_trx_id：表示在生成ReadView時(shí)，系統(tǒng)應(yīng)該分配給下一個(gè)事務(wù)的id。
- creator_trx_id：表示生成該ReadView的事務(wù)id。
有了這個(gè)ReadView，只要按照下面的判斷方式就可以解決“我到底可以讀取這個(gè)數(shù)據(jù)的哪個(gè)版本”這個(gè)千古難題了：
- 如果被訪問(wèn)的版本的trx_id和ReadView中的creator_trx_id相同，就意味著當(dāng)前版本就是由你“造成”的，可以讀出來(lái)。
- 如果被訪問(wèn)的版本的trx_id小于ReadView中的min_trx_id，表示生成該版本的事務(wù)在創(chuàng)建ReadView的時(shí)候，已經(jīng)提交了，所以該版本可以讀出來(lái)。
- 如果被訪問(wèn)版本的trx_id大于或等于ReadView中的max_trx_id值，說(shuō)明生成該版本的事務(wù)在當(dāng)前事務(wù)生成ReadView后才開(kāi)啟，所以該版本不可以被讀出來(lái)。
- 如果生成被訪問(wèn)版本的trx_id在min_trx_id和max_trx_id之間，那就需要判斷下trx_id在不在m_ids中：如果在，說(shuō)明創(chuàng)建ReadView的時(shí)候，生成該版本的事務(wù)還是活躍的（沒(méi)有被提交），該版本不可以被讀出來(lái)；如果不在，說(shuō)明創(chuàng)建ReadView的時(shí)候，生成該版本的事務(wù)已經(jīng)被提交了，該版本可以被讀出來(lái)。
如果某個(gè)數(shù)據(jù)的最新版本不可以被讀出來(lái)，就順著roll_pointer找到該數(shù)據(jù)的上一個(gè)版本，繼續(xù)做如上的判斷，以此類推，如果第一個(gè)版本也不可見(jiàn)的話，代表該數(shù)據(jù)對(duì)當(dāng)前事務(wù)完全不可見(jiàn)，查詢結(jié)果就不包含這條記錄了。
看完上面的描述，是不是覺(jué)得“云里霧里”，“不知所云”，甚至“腦闊疼，整個(gè)人都不好了”。
我們換個(gè)方法來(lái)解釋，看會(huì)不會(huì)更容易理解點(diǎn)：
在事務(wù)啟動(dòng)的一瞬間（執(zhí)行CURD操作），會(huì)創(chuàng)建出ReadView，對(duì)于一個(gè)數(shù)據(jù)版本的trx_id來(lái)說(shuō)，有以下三種情況：
- 如果落在低水位，表示生成這個(gè)版本的事務(wù)已經(jīng)提交了，或者是當(dāng)前事務(wù)自己生成的，這個(gè)版本可見(jiàn)。
- 如果落在高水位，表示生成這個(gè)版本的事務(wù)是未來(lái)才創(chuàng)建的，這個(gè)版本不可見(jiàn)。
- 如果落在中間水位，包含兩種情況：
a. 如果當(dāng)前版本的trx_id在活躍事務(wù)列表中，代表這個(gè)版本是由還沒(méi)有提交的事務(wù)生成的，這個(gè)版本不可見(jiàn)；
b. 如果當(dāng)前版本的trx_id不在活躍事務(wù)列表中，代表這個(gè)版本是由已經(jīng)提交的事務(wù)生成的，這個(gè)版本可見(jiàn)。
上面我比較簡(jiǎn)單的解釋了下ReadView，用了兩種方式來(lái)說(shuō)明如何判斷當(dāng)前數(shù)據(jù)版本是否可見(jiàn)，不知道各位看官是不是有了一個(gè)比較模糊的概念，有了ReadView的基本概念，我們就可以具體看下READ COMMITTED、REPEATABLE READ這兩個(gè)事務(wù)隔離級(jí)別為什么讀到的數(shù)據(jù)是不同的，以及上述規(guī)則是如何應(yīng)用的。
READ COMMITTED——每次讀取數(shù)據(jù)都會(huì)創(chuàng)建ReadView
假設(shè)，現(xiàn)在系統(tǒng)只有一個(gè)活躍的事務(wù)T，事務(wù)id是100，事務(wù)中修改了數(shù)據(jù)，但是還沒(méi)有提交，形成的版本鏈?zhǔn)沁@樣的：
現(xiàn)在A事務(wù)啟動(dòng)，并且執(zhí)行了select語(yǔ)句，此時(shí)會(huì)創(chuàng)建出一個(gè)ReadView，m_ids是【100】，min_trx_id是100， max_trx_id是101，creator_trx_id是0。
為什么m_ids只有一個(gè)，為什么creator_trx_id是0？這里再次強(qiáng)調(diào)下，只有在事務(wù)中執(zhí)行insert/update/delete語(yǔ)句才能獲得事務(wù)id。
那么A事務(wù)執(zhí)行的select語(yǔ)句會(huì)讀到什么數(shù)據(jù)呢？
- 判斷最新的數(shù)據(jù)版本，name是“夢(mèng)境地底王”，對(duì)應(yīng)的trx_id是100，trx_id在m_ids里面，說(shuō)明當(dāng)前事務(wù)是活躍事務(wù)，這個(gè)數(shù)據(jù)版本是由還沒(méi)有提交的事務(wù)創(chuàng)建的，所以這個(gè)版本不可見(jiàn)。
- 順著roll_pointer找到這個(gè)數(shù)據(jù)的上一個(gè)版本，name是“地底王”，對(duì)應(yīng)的trx_id是99，而ReadView中的min_trx_id是100，trx_id<min_trx_id，代表當(dāng)前數(shù)據(jù)版本是由已經(jīng)提交的事務(wù)創(chuàng)建的，該版本可見(jiàn)。
所以讀到的數(shù)據(jù)的name是“地底王”。
我們把事務(wù)T提交了，事務(wù)A再次執(zhí)行select語(yǔ)句，此時(shí)，事務(wù)A再次創(chuàng)建出ReadView，m_ids是【】，min_trx_id是0， max_trx_id是101，creator_trx_id是0。
因?yàn)槭聞?wù)T已經(jīng)提交了，所以沒(méi)有活躍的事務(wù)。
那么事務(wù)A第二次執(zhí)行select語(yǔ)句又會(huì)讀到什么數(shù)據(jù)呢？
- 判斷最新的數(shù)據(jù)版本，name是“夢(mèng)境地底王”，對(duì)應(yīng)的trx_id是100，不在m_ids里面，說(shuō)明這個(gè)數(shù)據(jù)版本是由已經(jīng)提交的事務(wù)創(chuàng)建的，該版本可見(jiàn)。
所以讀到的數(shù)據(jù)的name是“夢(mèng)境地底王”。
REPEATABLE READ ——首次讀取數(shù)據(jù)會(huì)創(chuàng)建ReadView
假設(shè)，現(xiàn)在系統(tǒng)只有一個(gè)活躍的事務(wù)T，事務(wù)id是100，事務(wù)中修改了數(shù)據(jù)，但是還沒(méi)有提交，形成的版本鏈?zhǔn)沁@樣的：
現(xiàn)在A事務(wù)啟動(dòng)，并且執(zhí)行了select語(yǔ)句，此時(shí)會(huì)創(chuàng)建出一個(gè)ReadView，m_ids是【100】，min_trx_id是100， max_trx_id是101，creator_trx_id是0。
那么A事務(wù)執(zhí)行的select語(yǔ)句會(huì)讀到什么數(shù)據(jù)呢？
- 判斷最新的數(shù)據(jù)版本，name是“夢(mèng)境地底王”，對(duì)應(yīng)的trx_id是100，trx_id在m_ids里面，說(shuō)明當(dāng)前事務(wù)是活躍事務(wù)，這個(gè)數(shù)據(jù)版本是由還沒(méi)有提交的事務(wù)創(chuàng)建的，所以這個(gè)版本不可見(jiàn)。
- 順著roll_ponit找到這個(gè)數(shù)據(jù)的上一個(gè)版本，name是“地底王”，對(duì)應(yīng)的trx_id是99，而ReadView中的min_trx_id是100，trx_id<min_trx_id，代表當(dāng)前數(shù)據(jù)版本是由已經(jīng)提交的事務(wù)創(chuàng)建的，該版本可見(jiàn)。
所以讀到的數(shù)據(jù)的name是“地底王”。
細(xì)心的你，一定發(fā)現(xiàn)了，這里我就是復(fù)制粘貼，因?yàn)樵赗EPEATABLE READ事務(wù)隔離級(jí)別下，事務(wù)A首次執(zhí)行select語(yǔ)句創(chuàng)建出來(lái)的ReadView和在READ COMMITTED事務(wù)隔離級(jí)別下，事務(wù)A首次執(zhí)行select語(yǔ)句創(chuàng)建出來(lái)的ReadView是一樣的，所以判斷流程也是一樣的，所以我就偷懶了，copy走起。
隨后，事務(wù)T提交了事務(wù)，由于REPEATABLE READ是首次讀取數(shù)據(jù)才會(huì)創(chuàng)建ReadView，所以事務(wù)A再次執(zhí)行select語(yǔ)句，不會(huì)再創(chuàng)建ReadView，用的還是上一次的ReadView，所以判斷流程和上面也是一樣的，所以讀到的name還是“地底王”。
本篇博客到這里就結(jié)束了。
