SQL事物機制特性

1. 事務

事務是指一個或者多個數(shù)據(jù)庫操作，要么全部沒有執(zhí)行，要么全部成功執(zhí)行。

中途失敗需要回滾到指定狀態(tài)，全部執(zhí)行成功需要確保持久保存在數(shù)據(jù)庫中。

事務擁有四個特性，習慣上被稱之為ACID特性。

2. ACID特性

為了更直觀的解釋ACID特性，下面先說明A, B, C之間互相轉(zhuǎn)賬的過程。

假設A有10元，B有15元，C有8元

A給B轉(zhuǎn)賬5元，操作記為T1。

T1: read(A), A=A-5, write(A), read(B), B=B+5, write(B)。

T1操作的大體流程，先讀取A到賬戶余額，將A的賬戶余額扣減5元后再寫入數(shù)據(jù)庫中，

讀取B的賬戶余額，將B的賬戶余額增加5元后再寫入到數(shù)據(jù)庫中。

同時，C給B轉(zhuǎn)賬4元，操作記為T2。

T2: read(C), C=C-4, write(C), read(B), B=B+4, write(B)

T1操作的大體流程，先讀取C的賬戶余額，將C的賬戶余額扣減4元后再寫入數(shù)據(jù)庫中，

讀取B的賬戶余額，將B的賬戶余額增加4元后再寫入到數(shù)據(jù)庫中。

2.1 原子性(Atomicity)

事務作為一個整體被執(zhí)行，包含在其中的對數(shù)據(jù)庫的操作要么全部被執(zhí)行，要么都不執(zhí)行，是一個最小執(zhí)行單元，不可分割。

A給B轉(zhuǎn)賬5元的操作T1是包含多個讀寫操作，這些操作要么全部執(zhí)行，要么全部不執(zhí)行。

假設由于斷電等意外事件，導致T1只執(zhí)行了部分操作，如T1:read(A), A=A-5, write(A)

這就會導致A憑空少了5元，并且B沒有收到A轉(zhuǎn)的5元，

因此事務需要保證保證在事務執(zhí)行過程中出現(xiàn)錯誤時，將已經(jīng)執(zhí)行的操作“撤銷”，恢復到原始狀態(tài)。

2.2 一致性(Consistency)

事務應確保數(shù)據(jù)庫的狀態(tài)從一個一致狀態(tài)轉(zhuǎn)變?yōu)榱硪粋€一致狀態(tài)。

假設A有10元，B有15元，C有8元，不管A, B, C之間如何進行轉(zhuǎn)賬(沒有其他人參與)，三個點賬戶總余額一定是33元，而不會是其它值。

2.3 隔離性(Isolation)

多個事務并發(fā)執(zhí)行時，一個事務的執(zhí)行不應影響其他事務的執(zhí)行。

A給B轉(zhuǎn)賬5元，同時C給B轉(zhuǎn)賬4元，這個兩個事務應該是互相隔離的，互不影響。

最終A余額為5元，C余額為4元，B總共收到兩次轉(zhuǎn)賬，余額應該為24元。

假設T1, T2可以交叉執(zhí)行，如下圖所示。最終結(jié)果看起來B只收到了A的5元轉(zhuǎn)賬，余額為20元。

2.4 持久性(Durability)

已被提交的事務對數(shù)據(jù)庫的修改應該永久保存在數(shù)據(jù)庫中。

MySQL操作一般是先寫入緩存，滿足指定條件后才將緩存更新到磁盤

磁盤寫操作相當耗時，而且同一個事務可能修改多個數(shù)據(jù)頁面，而且可能執(zhí)行頁面中一個字節(jié)的數(shù)據(jù)。

因此每次數(shù)據(jù)庫提交執(zhí)行緩存刷新磁盤操作不太合理，

MySQL設計人員通過redo日志來持久化最小量的數(shù)據(jù)來達到相同的效果。

3. redo日志

為了保證事務的持久性，在事務提交動作完成之前，需要把該事務修改所有頁面都刷新到磁盤，但是存在以下問題

隨機I/O比較慢，一個事務可能修改到多個頁面，這些頁面在磁盤中可能不相鄰，可能需要多次長距離移動磁盤讀寫磁頭。

刷新完整的數(shù)據(jù)頁面較慢，一個事務也可能值修改頁面中一個字節(jié)，卻要同步整個頁面到磁盤上。

為了解決上述到問題，InnoDB設計了redo日志，把事務修改的內(nèi)容采用特定的格式按順序保存到磁盤上，

即使在系統(tǒng)崩潰之后，按照redo日志重新更改數(shù)據(jù)頁進行數(shù)據(jù)恢復即可。

3.1 redo日志格式

redo日志通用格式如下圖所示

type，redo日志類型，通過定義不同類型可以達到節(jié)省空間的目的

space id，表空間id

page number，頁號

data，redo日志具體內(nèi)容

往表中插入一條記錄，可能產(chǎn)生多條redo日志，因為可能產(chǎn)生聚簇索引對應B+樹頁面的分裂操作，

可能需要性申請數(shù)據(jù)頁，金額可能要修改各種段、區(qū)的統(tǒng)計信息等，

最終插入一條記錄可能產(chǎn)生多條redo日志，這些日志是不可分割的，

在崩潰恢復時，也是將這一組日志作為不可分割的整體來處理，

類似的，將一組不可分割的redo日志稱為Mini-Transaction，即MTR

3.2 redo日志緩沖區(qū)

為了避免頻繁的磁盤IO，并不是每生成一條redo日志就同步到磁盤上。

而是先將redo日志放到緩沖區(qū)，在特定時機刷新到磁盤。

redo日志緩沖區(qū)頁面結(jié)構(gòu)如下圖所示。

redo日志是以MTR為單位寫入到redo日志緩沖區(qū)的，redo日志緩沖區(qū)是有若干個512B大小的block構(gòu)成的一片連續(xù)的內(nèi)存空間，

InnoDB引擎使用lsn(log sequence number)來記錄系統(tǒng)當前有多少redo日志寫入到緩沖區(qū)

3.3 redo日志文件

3.3.1 flush鏈表中的lsn

InnoDB會將lsn相關信息寫入到flush鏈表中，進而方便判斷哪些redo日志文件可以被重復使用，

因為只要臟頁被刷新到磁盤，相應的redo日志內(nèi)容就沒有存在的意義了，而且redo日志文件大小也有限。

Buffer Pool中頁面會在控制塊中記錄頁面的修改信息

oldest_modification: 第一次修改Buffer Pool中某個頁面時，將MTR開始時的lsn寫入該變量

newest_modification: 每次修改Buffer Pool中某個頁面時，將MTR結(jié)束時的lsn寫入該變量

flush鏈表與oldest_modification(o_m)和newest_modification(n_m)的關系如下圖所示。

flush鏈表的基節(jié)點start指針出發(fā)，flush鏈表的臟頁時按照第一次修改發(fā)生的時間倒序排列的，也就是按照oldest_modification代表的lsn值倒敘排列，

當頁面被多次更新時，會更新對應頁面的newest_modification變量的值。

當頁面1被屬性到磁盤，從頁面2的控制塊可以看出，lsn低于8916的redo日志可以被覆蓋，系統(tǒng)會將8916賦值到redo文件的checkpoint_lsn的操作。

InnoDB將檢查flush鏈表最小的oldest_modification的lsn值稱為checkpoint操作。

3.3.2 redo日志文件格式

磁盤上存在多個redo日志文件，會被循環(huán)使用，這一組redo日志文件稱為redo日志文件組。

和redo日志緩沖區(qū)一樣，redo日志文件也是由若干個512B構(gòu)成的block組成

其中，redo日志文件的頭2048個字節(jié)用于存儲一些管理信息，系統(tǒng)會將checkpoint操作得到的checkpoint_lsn賦值到checkpoint1的checkpoint_lsn上。

崩潰恢復會從checkpoint_lsn在日志文件組中對應的偏移量開始。

除了前面闡述的checkpoint，redo日志刷盤時機還包括

redo日志緩存不足時

事務提交時

后臺線程周期性刷盤

正常關閉服務器

3.3.3 奔潰恢復

當遇到異常情況導致服務器掛掉，在重啟時可以根據(jù)redo日志文件恢復到奔潰前的狀態(tài)。

InnoDB從redo日志文件組的第一個文件的checkpoint信息，然后從checkpoint_lsn在日志文件組中對應的偏移量開始，

一直掃描日志文件中的，直到某個block的寫入量的值不等于512，根據(jù)redo日志格式將修改的內(nèi)容恢復到奔潰前狀態(tài)。

4. undo日志

在事務執(zhí)行過程中可能遇到各種錯誤，導致中途就結(jié)束事務了，但是在遇到錯誤退出前，可能修改多個行記錄，

但是為了保證事務的原子性，需要將數(shù)據(jù)恢復到事務開啟前，這個恢復過程就稱為回滾。

為了回滾，就需要將事務修改的內(nèi)容記錄下來，包括插入的行記錄、修改行記錄的內(nèi)容、刪除的行記錄，

保存事務執(zhí)行過程中修改內(nèi)容的東西稱為undo日志。

4.1 undo日志格式

4.1.1 聚簇索引行結(jié)構(gòu)

InnoDB會將聚簇索引行結(jié)構(gòu)如下圖所示

InnoDB會將聚簇索引行結(jié)構(gòu)補充trx_id和roll_pointer兩個隱藏列

trx_id: 一個事務某次對某條聚簇索引記錄進行改動時，都會把該事務的事務ID賦值給trx_id，事務ID是單調(diào)遞增的

roll_pointer: 每次對某條聚簇索引進行改動時，都會把舊版本寫入到undo日志中，并以聚簇索引為起點構(gòu)成一個從最新到最舊的單向鏈表結(jié)構(gòu)，這個鏈表就稱為版本鏈

roll_pointer結(jié)構(gòu)如下圖所示

is_insert, 表示該指針指向的undo日志是否是TRX_UNDO_INSERT大類的undo日志

resg id, 表示該指針指向的undo日志的回滾段編號

page number, 表示該指針指向的undo日志所在頁面的頁號

offset, 表示該指針指向的undo日志在頁面中的偏移量

4.1.2 插入操作

如果需要回滾插入操作，只需要將插入的記錄刪除即可，

因此在記錄undo日志時，只需要記錄插入的記錄的主鍵信息即可，通過主鍵能找到唯一的記錄

插入操作的對應的undo日志類型為TRX_UNDO_INSERT_REC，結(jié)構(gòu)如下圖所示

undo type, 即TRX_UNDO_INSERT_REC

undo no, 事務執(zhí)行過程中，每生成一條undo日志，undo no就增加1，且從0開始

table id, 該undo日志對應的記錄所在表的table id

4.1.3 刪除操作

在事務中執(zhí)行刪除操作，會將記錄的deleted_flag標識為值為1，但該記錄依然在正常記錄鏈表，并沒有移動到垃圾記錄鏈表，這個過程稱為delete mark。

在事務提交后，才把該記錄從正常記錄鏈表挪到垃圾記錄鏈表

刪除操作產(chǎn)生TRX_UNDO_DEL_MARK_REC類型的日志，結(jié)構(gòu)如下圖所示，

在對一條記錄進行delete mark操作前，將該記錄的trx_id和roll_pointer的舊值保存到undo日志的trx_id和roll_pointer變量中。

假設一個事務對某條記錄先更新再刪除，這樣就能通過TRX_UNDO_DEL_MARK_REC找到更新的undo日志。

4.2.4 更新操作

更新操作的場景較復雜，InnoDB將其分為更新主鍵和不更新主鍵兩種場景。

不更新主鍵

更新的每個列在更新前后占用的存儲空間不變，則可以進行就地更新

更新前后占用存儲空間有變，需要將舊記錄從聚簇索引刪除，再創(chuàng)建一條新的記錄

更新主鍵，舊記錄執(zhí)行delete mark操作，創(chuàng)建新紀錄插入聚簇索引

針對以上各種情況，InnnoDB設計了對應的undo日志格式，限于篇幅這里就不展開說明。

4.2 undo日志頁面

和InnoDB普通頁面結(jié)構(gòu)類型，undo日志頁面結(jié)構(gòu)及頁面鏈表如下圖所示。

一個undo日志頁面只能存儲一種類型，InnoDB將undo日志分為兩大類，

TRX_UNDO_INSERT，由insert語句產(chǎn)生undo日志，或者update語句更新主鍵也會產(chǎn)生該類型的undo日志

TRX_UNDO_UPDATE，除了TRX_UNDO_INSERT類型的undo日志，其它類型的undo日志都屬于這個大類

InnoDB對臨時表和普通表產(chǎn)生的undo日志分開記錄，因此一個事務最多可能需要4個undo頁面鏈表。

4.3 回滾

同一個時刻，可能存在多個事務在執(zhí)行，為了更好的管理undo頁面鏈表，

InnoDB設計了Rollback Segment Header頁面用于存放各個Undo頁面鏈表的第一個undo頁面的頁號，即undo slot。

在奔潰恢復時，需要將未提交事務的修改回滾掉，通過undo slot找到undo頁面鏈表，

通過判斷undo頁面鏈表的Undo Log SegmentHeader的TRX_UNDO_STATE屬性值，

如果為TRX_UNDO_ACTIVE，則進一步通過undo鏈表最后一個頁面的Undo Log Header中找到該事務對應的事務ID，

然后通過undo日志內(nèi)容將該事務修改的內(nèi)容全部撤銷，從而保證事務的原子性。

5. 事務隔離級別和MVCC

5.1 常見一致性問題

臟寫(Dirty Write)

一個事務修改了另外一個未提交事務修改過的數(shù)據(jù)。

臟讀(Dirty Read)

一個事務讀取了另外一個未提交事務修改過的數(shù)據(jù)。

不可重復讀(Non-repeatable Read)

一個事務修改了另一個未提交事務讀取的數(shù)據(jù)。

幻讀(Phantom)

一個事務根據(jù)某些搜索條件查詢出一些記錄，在該事務未提交時，另一個事務寫入了一些符合搜索條件的記錄，

再次以相同條件查詢，前后兩次結(jié)果不一致。

5.2 事務隔離級別

SQL標準中定義了四種隔離級別

讀未提交(Read Uncommitted), 讀已提交(Read Committed), 可重復讀(Repeatable Read), 串行化(Serializable)。

不同隔離級別對應的可能和不可能發(fā)生的一致性問題如下圖所示。

其中臟寫問題是不允許發(fā)生的。

5.3 MVCC

5.3.1 版本鏈

InnnoDB存儲引擎的聚簇索引的版本鏈如下圖所示

假設在某個時刻，事務321、315、301對某條記錄進行Updata操作后，形成的版本鏈如下圖所示。其中事務301對這條記錄更新了兩次

5.3.2 MVCC和ReadView

Multi-Version Concurrency Control, 即多版本并發(fā)控制，

多版本并發(fā)控制機制利用聚簇索引的版本鏈來控制并發(fā)事務訪問相同記錄時的行為，從而解決臟讀和不可重復讀的不一致性問題。

ReadView，即一致性視圖，通過這個視圖可以判斷版本鏈的某個版本是否可被當前事務訪問，中ReadView包含以下4個比較重要的數(shù)據(jù)

creator_trx_id，生成該ReadView的事務對應的事務ID

m_ids，在生成ReadView時當前系統(tǒng)中活躍的事務ID列表

min_trx_id，m_ids的最小值

max_trx_id，生成ReadView時，系統(tǒng)的下一個事務ID值。

判斷是否可見的規(guī)則

如果被訪問版本的trx_id值與ReadView中的creator_trx_id值相同，說明是當前事務在訪問自己修改過的記錄，該版本可以被當前事務訪問

如果被訪問版本的trx_id值小于ReadView中min_trx_id值，說明該版本在當前事務生成ReadView前已經(jīng)提交，因此該版本可以被訪問

如果被訪問版本的trx_id值不小于ReadView中的max_trx_id值，說明該版本的事務在當前事務生成ReadView后啟動，因此該版本不可訪問

如果被訪問版本的trx_id值在ReadView的min_trx_id和max_trx_id之間

如果trx_id在m_ids列表中，說明ReadView生成時該版本的事務依然活躍，因此該版本不可訪問

如果trx_id不在在m_ids列表中，說明ReadView生成時該版本的事務已經(jīng)提交，因此該版本可以被訪問

順著版本鏈重復上述操作，直到找到可以訪問的版本，或者到達版本鏈末尾。如果版本鏈最后一個版本依然不可見，則查詢結(jié)果為記錄不存在

在讀已提交和可重復讀隔離級別下，ReadView生成的時機有所不同，

讀已提交在每一次進行普通Select操作前都會生成一個ReadView，確保了讀取到都是已提交事務的數(shù)據(jù)

可重復讀只在第一次進行普通Select操作前生產(chǎn)一個ReadView, 之后查詢操作都重復使用這個ReadView，保證了同一個事務內(nèi)不同時間讀到相同數(shù)據(jù)