MySQL事務(wù)原子性保證
事務(wù)原子性要求事務(wù)中的一系列操作要么全部完成，要么不做任何操作，不能只做一半。原子性對于原子操作很容易實(shí)現(xiàn)，就像HBase中行級事務(wù)的原子性實(shí)現(xiàn)就比較簡單。但對于多條語句組成的事務(wù)來說，如果事務(wù)執(zhí)行過程中發(fā)生異常，需要保證原子性就只能回滾，回滾到事務(wù)開始前的狀態(tài)，就像這個事務(wù)根本沒有發(fā)生過一樣。如何實(shí)現(xiàn)呢？
MySQL實(shí)現(xiàn)回滾操作完全依賴于undo log，多說一句，undo log在MySQL除了用來實(shí)現(xiàn)原子性保證之外，還用來實(shí)現(xiàn)MVCC，下文也會涉及到。使用undo實(shí)現(xiàn)原子性在操作任何數(shù)據(jù)之前，首先會將修改前的數(shù)據(jù)記錄到undo log中，再進(jìn)行實(shí)際修改。如果出現(xiàn)異常需要回滾，系統(tǒng)可以利用undo中的備份將數(shù)據(jù)恢復(fù)到事務(wù)開始之前的狀態(tài)。下圖是MySQL中表示事務(wù)的基本數(shù)據(jù)結(jié)構(gòu)，其中與undo相關(guān)的字段為insert_undo和update_undo，分別指向本次事務(wù)所產(chǎn)生的undo log。
事務(wù)回滾根據(jù)update_undo（或者insert_undo）找到對應(yīng)的undo log，做逆向操作即可。對于已經(jīng)標(biāo)記刪除的數(shù)據(jù)清理刪除標(biāo)記，對于更新數(shù)據(jù)直接回滾更新；插入操作稍微復(fù)雜一些，不僅需要刪除數(shù)據(jù)，還需要刪除相關(guān)的聚集索引以及二級索引記錄。
undo log是MySQL內(nèi)核中非常重要的一塊內(nèi)容，涉及知識比較多而且復(fù)雜，比如：
1. undo log必須在數(shù)據(jù)修改之前持久化，undo log持久化需不需要記錄redo以防止宕機(jī)異常？如果需要就又涉及宕機(jī)恢復(fù)…
2. 通過undo log如何實(shí)現(xiàn)MVCC？
3. 那些undo log可以在什么場景下回收清理？如何清理？
MySQL事務(wù)一致性保證：強(qiáng)一致性事務(wù)保證
MySQL事務(wù)隔離級別
Read Uncommitted（RU技術(shù)解讀：使用X鎖實(shí)現(xiàn)寫寫并發(fā)）
Read Uncommitted只實(shí)現(xiàn)了寫寫并發(fā)控制，并沒有有效的讀寫并發(fā)控制，導(dǎo)致當(dāng)前事務(wù)可能讀到其他事務(wù)中還未提交的修改數(shù)據(jù)，這些數(shù)據(jù)準(zhǔn)確性并不靠譜（有可能被回滾掉），因此在此基礎(chǔ)上作出的一切假設(shè)就都不靠譜的。在現(xiàn)實(shí)場景中很少有業(yè)務(wù)會選擇該隔離級別。
寫寫并發(fā)實(shí)現(xiàn)機(jī)制和HBase并無兩樣，都是使用兩階段鎖協(xié)議對相應(yīng)記錄加行鎖實(shí)現(xiàn)。不過MySQL中行鎖機(jī)制比較復(fù)雜，根據(jù)行記錄是否是主鍵索引、唯一索引、非唯一索引或者無索引等分為多種加鎖情況。這里舉個簡單例子做下說明：update user set userName =?“l(fā)ibis” where id = 15。（如果大家有興趣，可以參考登博的這篇文章：《MySQL加鎖處理分析》）
1. 如果id列是主鍵索引，MySQL只會為聚簇索引記錄加鎖。
2. 如果id列是唯一二級索引，MySQL會為二級索引葉子節(jié)點(diǎn)以及聚簇索引記錄加鎖。
3. 如果id列是非唯一索引，MySQL會為所有滿足條件(id = 15)的二級索引葉子節(jié)點(diǎn)以及對應(yīng)的聚簇索引記錄加鎖。
4. 如果id列是無索引的，SQL會走聚簇索引全表掃描，并將掃描結(jié)果加載到SQL Server層進(jìn)行過濾，因此InnoDB會為掃描過的所有記錄先加上鎖，如果SQL Server層過濾不符合條件，InnoDB會釋放該鎖。因此InnoDB會為掃描到的所有記錄都加鎖，很恐怖吧!
接下來無論是RC、RR，抑或是Serialization，寫寫并發(fā)控制都使用上述機(jī)制，所以不再贅述。接下來會重點(diǎn)分析RC和RR隔離級別中的讀寫并發(fā)控制機(jī)制。
在詳細(xì)介紹RC和RR之前，有必要在此先行介紹MySQL中MVCC機(jī)制，因?yàn)镽C和RR都使用MVCC機(jī)制實(shí)現(xiàn)事務(wù)之間的讀寫并發(fā)。只不過兩者在實(shí)現(xiàn)細(xì)節(jié)上有一些區(qū)別，具體區(qū)別接下來再聊。
MVCC in MySQL
MySQL中MVCC機(jī)制相比HBase來說要復(fù)雜的多，涉及的數(shù)據(jù)結(jié)構(gòu)也比較復(fù)雜。為了解釋的比較清晰，以一個栗子為模版進(jìn)行解釋。比如當(dāng)前有一行記錄如下圖所示：
前面四列是該行記錄的實(shí)際列值，需要重點(diǎn)關(guān)注的是DB_TRX_ID和DB_ROLL_PTR兩個隱藏列（對用戶不可見）。其中DB_TRX_ID表示修改該行事務(wù)的事務(wù)ID，而DB_ROLL_PTR表示指向該行回滾段的指針，該行記錄上所有版本數(shù)據(jù)，在undo中都通過鏈表形式組織，該值實(shí)際指向undo中該行的歷史記錄鏈表。
現(xiàn)在假設(shè)有一個事務(wù)trx2修改了該行數(shù)據(jù)，該行記錄就會變?yōu)橄聢D形式，DB_TRX_ID為最近修改該行事務(wù)的事務(wù)ID(trx2)，DB_ROLL_PTR指向undo歷史紀(jì)錄鏈表：
了解了MySQL行記錄之后，再來看看事務(wù)的基本結(jié)構(gòu)，下圖是MySQL的事務(wù)數(shù)據(jù)結(jié)構(gòu)，上文我們提到過。事務(wù)在開啟之后會創(chuàng)建一個數(shù)據(jù)結(jié)構(gòu)存儲事務(wù)相關(guān)信息、鎖信息、undo log以及非常重要的read_view信息。
read_view保存了當(dāng)前事務(wù)開啟時整個MySQL中所有活躍事務(wù)列表，如下圖所示，在當(dāng)前事務(wù)開啟的時候，系統(tǒng)中活躍的事務(wù)有trx4、trx6、trx7以及trx10。另外，up_trx_id表示當(dāng)前事務(wù)啟動時，當(dāng)前事務(wù)鏈表中最小的事務(wù)ID；low_trx_id表示當(dāng)前事務(wù)啟動時，當(dāng)前事務(wù)鏈表中最大的事務(wù)ID。
read_view是實(shí)現(xiàn)MVCC的一個關(guān)鍵點(diǎn)，它用來判斷記錄的哪個版本對當(dāng)前事務(wù)可見。如果當(dāng)前事務(wù)要讀取某行記錄，該行記錄的版本號（事務(wù)ID）為trxid，那么：
1. 如果trxid < up_trx_id，說明該行記錄所在的事務(wù)已經(jīng)在當(dāng)前事務(wù)創(chuàng)建之前就提交了，所以該行記錄對當(dāng)前事務(wù)可見。
2. 如果trxid > low_trx_id，說明該行事務(wù)所在的事務(wù)是在當(dāng)前事務(wù)創(chuàng)建之后才開啟，所以該行記錄對當(dāng)前事務(wù)不可見。
3. 如果up_trx_id < trxid < low_trx_id，那么表明該行記錄所在事務(wù)在本次新事務(wù)創(chuàng)建的時候處于活動狀態(tài)。從up_trx_id到low_trx_id進(jìn)行遍歷，如果trxid等于他們之中的某個事務(wù)id的話，那么不可見，否則可見。
以下面行記錄為例，該行記錄存在多個版本（trx2、trx5、trx7以及trx12），其中trx12是最新版本?？纯丛撔杏涗浿心膫€版本對當(dāng)前事務(wù)可見。
1. 該行記錄的最新版本為trx12，與當(dāng)前事務(wù)read_view進(jìn)行對比發(fā)現(xiàn)，trx12大于當(dāng)前活躍事務(wù)列表中的最大事務(wù)trx10，表示trx12是在當(dāng)前事務(wù)創(chuàng)建之后才開啟的，因此不可見。
2. 再查看該行記錄的第二個最新版本為trx7，與當(dāng)前事務(wù)read_view對比發(fā)現(xiàn)，trx7介于當(dāng)前活躍事務(wù)列表最小事務(wù)ID和最大事務(wù)ID之間，表明該行記錄所在事務(wù)在當(dāng)前事務(wù)創(chuàng)建的時候處于活動狀態(tài)，在活躍列表中遍歷發(fā)現(xiàn)trx7確實(shí)存在，說明該事務(wù)還沒有提交，所以對當(dāng)前事務(wù)不可見。
3. 繼續(xù)查看該記錄的第三個最新版本trx5，也介于當(dāng)前活躍事務(wù)列表最小事務(wù)ID和最大事務(wù)ID之間，表明該行記錄所在事務(wù)在當(dāng)前事務(wù)創(chuàng)建的時候處于活動狀態(tài)，但遍歷發(fā)現(xiàn)該版本并不在活躍事務(wù)列表中，說明trx5對應(yīng)事務(wù)已經(jīng)提交（注：事務(wù)提交時間與事務(wù)編號沒有任何關(guān)聯(lián)，有可能事務(wù)編號大的事務(wù)先提交，事務(wù)編號小的事務(wù)后提交），因此trx5版本行記錄對當(dāng)前事務(wù)可見，直接返回。
Read Committed（技術(shù)解讀：寫寫并發(fā)使用X鎖，讀寫并發(fā)使用MVCC避免臟讀）
上文介紹了MySQL中MVCC技術(shù)實(shí)現(xiàn)機(jī)制，但要明白RC隔離級別下事務(wù)可見性，還需要get一個核心點(diǎn)：RC隔離級別下的事務(wù)在每次執(zhí)行select時都會生成一個最新的read_view代替原有的read_view。
如上圖所示，左側(cè)為1號事務(wù)，在不同時間點(diǎn)對id=1的記錄分別查詢了三次。右側(cè)為2號事務(wù)，對id=1的記錄進(jìn)行了更新。更新前該記錄只有一個版本，更新好變成了兩個版本。
1號事務(wù)在RC隔離級別下每次執(zhí)行select請求都會生成一個最新的read_view，前兩次查詢生成的全局事務(wù)活躍列表中包含trx2，因此根據(jù)MVCC規(guī)定查到的記錄為老版本；最后一次查詢的時間點(diǎn)位于2號事務(wù)提交之后，因此生成的全局活躍事務(wù)列表中不包含trx2，此時在根據(jù)MVCC規(guī)定查到的記錄就是最新版本記錄。
Repeatable Read（
技術(shù)解讀：寫寫并發(fā)使用X鎖，讀寫并發(fā)使用MVCC避免不可重復(fù)讀；當(dāng)前讀使用Gap鎖避免幻讀）
和RC模式不同，RR模式下事務(wù)不會再每次執(zhí)行select的時候生成最新的read_view，而是在事務(wù)第一次select時就生成read_view，后續(xù)不會再變更，直至當(dāng)前事務(wù)結(jié)束。這樣可以有效避免不可重復(fù)讀，使得當(dāng)前事務(wù)在整個事務(wù)過程中讀到的數(shù)據(jù)都保持一致。示意圖如下所示：
這個就很容易理解，三次查詢所使用的全局活躍事務(wù)列表都一樣，且都是第一次生成的read_view，那之后查到的記錄必然和第一次查到的記錄一致。
RR隔離級別能夠避免幻讀嗎？
如果對幻讀還不了解的話，可以參考該系列的第一篇文章。如下圖所示，1號事務(wù)對針對id>1的過濾條件執(zhí)行了三次查詢，2號事務(wù)執(zhí)行了一次插入，插入的記錄剛好符合id>1這個條件?？梢钥闯鰜恚尾樵兊玫降臄?shù)據(jù)是一致的，這個是由RR隔離級別的MVCC機(jī)制保證的。這么看來，是避免了幻讀，但是在最后1號事務(wù)在id=2處插入一條記錄，MySQL會返回Duplicate entry的錯誤，可見避免了幻讀是一種假象。
嚴(yán)格意義避免幻讀（技術(shù)解讀：當(dāng)前讀使用Gap鎖避免幻讀）
之前提到的所有RR級別的select語句我們稱為快照讀，快照讀能夠保證不可重復(fù)讀，但并不能避免幻讀。于是MySQL又提出”當(dāng)前讀”的概念，常見的當(dāng)前讀語句有：
1. ?select for update
2. ?select lock in share mode
3. ?update / delete
并且規(guī)定，RR級別下當(dāng)前讀語句會給記錄加上一種特殊的鎖－Gap鎖，Gap鎖并不鎖定某個具體的記錄，而是鎖定記錄與記錄之間的間隔，保證這個間隔中不會插入新的其他記錄。下圖是一個示意圖：
上圖中1號事務(wù)首先執(zhí)行了一個當(dāng)前讀的select語句，這個語句會在 id > 0的所有間隔加上Gap鎖，接下來2號事務(wù)在id = 3處執(zhí)行插入時系統(tǒng)就會返回Lock wait timeout execcded的異常。當(dāng)然，其他事務(wù)可以在id <= 0的條件下插入成功，這沒問題。
