共計 5272 個字符，預計需要花費 14 分鐘才能閱讀完成。
本篇文章給大家分享的是有關 MySQL 中怎么實現跨行事務模型，丸趣 TV 小編覺得挺實用的，因此分享給大家學習，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著丸趣 TV 小編一起來看看吧。
MySQL 事務原子性保證
事務原子性要求事務中的一系列操作要么全部完成，要么不做任何操作，不能只做一半。原子性對于原子操作很容易實現，就像 HBase 中行級事務的原子性實現就比較簡單。但對于多條語句組成的事務來說，如果事務執行過程中發生異常，需要保證原子性就只能回滾，回滾到事務開始前的狀態，就像這個事務根本沒有發生過一樣。如何實現呢?
MySQL 實現回滾操作完全依賴于 undo log，多說一句，undo log 在 MySQL 除了用來實現原子性保證之外，還用來實現 MVCC，下文也會涉及到。使用 undo 實現原子性在操作任何數據之前，首先會將修改前的數據記錄到 undo log 中，再進行實際修改。如果出現異常需要回滾，系統可以利用 undo 中的備份將數據恢復到事務開始之前的狀態。下圖是 MySQL 中表示事務的基本數據結構，其中與 undo 相關的字段為 insert_undo 和 update_undo，分別指向本次事務所產生的 undo log。
事務回滾根據 update_undo(或者 insert_undo)找到對應的 undo log，做逆向操作即可。對于已經標記刪除的數據清理刪除標記，對于更新數據直接回滾更新; 插入操作稍微復雜一些，不僅需要刪除數據，還需要刪除相關的聚集索引以及二級索引記錄。
undo log 是 MySQL 內核中非常重要的一塊內容，涉及知識比較多而且復雜，比如：
1. undo log 必須在數據修改之前持久化，undo log 持久化需不需要記錄 redo 以防止宕機異常? 如果需要就又涉及宕機恢復 hellip;
2. 通過 undo log 如何實現 MVCC?
3. 那些 undo log 可以在什么場景下回收清理? 如何清理?
MySQL 事務一致性保證：強一致性事務保證
MySQL 事務隔離級別
Read Uncommitted(RU 技術解讀：使用 X 鎖實現寫寫并發)
Read Uncommitted 只實現了寫寫并發控制，并沒有有效的讀寫并發控制，導致當前事務可能讀到其他事務中還未提交的修改數據，這些數據準確性并不靠譜(有可能被回滾掉)，因此在此基礎上作出的一切假設就都不靠譜的。在現實場景中很少有業務會選擇該隔離級別。
寫寫并發實現機制和 HBase 并無兩樣，都是使用兩階段鎖協議對相應記錄加行鎖實現。不過 MySQL 中行鎖機制比較復雜，根據行記錄是否是主鍵索引、唯一索引、非唯一索引或者無索引等分為多種加鎖情況。
1. 如果 id 列是主鍵索引，MySQL 只會為聚簇索引記錄加鎖。
2. 如果 id 列是唯一二級索引，MySQL 會為二級索引葉子節點以及聚簇索引記錄加鎖。
3. 如果 id 列是非唯一索引，MySQL 會為所有滿足條件 (id = 15) 的二級索引葉子節點以及對應的聚簇索引記錄加鎖。
4. 如果 id 列是無索引的，SQL 會走聚簇索引全表掃描，并將掃描結果加載到 SQL Server 層進行過濾，因此 InnoDB 會為掃描過的所有記錄先加上鎖，如果 SQL Server 層過濾不符合條件，InnoDB 會釋放該鎖。因此 InnoDB 會為掃描到的所有記錄都加鎖，很恐怖吧!
接下來無論是 RC、RR，抑或是 Serialization，寫寫并發控制都使用上述機制，所以不再贅述。接下來會重點分析 RC 和 RR 隔離級別中的讀寫并發控制機制。
在詳細介紹 RC 和 RR 之前，有必要在此先行介紹 MySQL 中 MVCC 機制，因為 RC 和 RR 都使用 MVCC 機制實現事務之間的讀寫并發。只不過兩者在實現細節上有一些區別，具體區別接下來再聊。
MVCC in MySQL
MySQL 中 MVCC 機制相比 HBase 來說要復雜的多，涉及的數據結構也比較復雜。為了解釋的比較清晰，以一個栗子為模版進行解釋。比如當前有一行記錄如下圖所示：
前面四列是該行記錄的實際列值，需要重點關注的是 DB_TRX_ID 和 DB_ROLL_PTR 兩個隱藏列(對用戶不可見)。其中 DB_TRX_ID 表示修改該行事務的事務 ID，而 DB_ROLL_PTR 表示指向該行回滾段的指針，該行記錄上所有版本數據，在 undo 中都通過鏈表形式組織，該值實際指向 undo 中該行的歷史記錄鏈表。
現在假設有一個事務 trx2 修改了該行數據，該行記錄就會變為下圖形式，DB_TRX_ID 為最近修改該行事務的事務 ID(trx2)，DB_ROLL_PTR 指向 undo 歷史紀錄鏈表：
了解了 MySQL 行記錄之后，再來看看事務的基本結構，下圖是 MySQL 的事務數據結構，上文我們提到過。事務在開啟之后會創建一個數據結構存儲事務相關信息、鎖信息、undo log 以及非常重要的 read_view 信息。
read_view 保存了當前事務開啟時整個 MySQL 中所有活躍事務列表，如下圖所示，在當前事務開啟的時候，系統中活躍的事務有 trx4、trx6、trx7 以及 trx10。另外，up_trx_id 表示當前事務啟動時，當前事務鏈表中最小的事務 ID;low_trx_id 表示當前事務啟動時，當前事務鏈表中最大的事務 ID。
read_view 是實現 MVCC 的一個關鍵點，它用來判斷記錄的哪個版本對當前事務可見。如果當前事務要讀取某行記錄，該行記錄的版本號 (事務 ID) 為 trxid，那么：
1. 如果 trxid up_trx_id，說明該行記錄所在的事務已經在當前事務創建之前就提交了，所以該行記錄對當前事務可見。
2. 如果 trxid low_trx_id，說明該行事務所在的事務是在當前事務創建之后才開啟，所以該行記錄對當前事務不可見。
3. 如果 up_trx_id trxid low_trx_id， 那么表明該行記錄所在事務在本次新事務創建的時候處于活動狀態。從 up_trx_id 到 low_trx_id 進行遍歷，如果 trxid 等于他們之中的某個事務 id 的話，那么不可見，否則可見。
以下面行記錄為例，該行記錄存在多個版本(trx2、trx5、trx7 以及 trx12)，其中 trx12 是最新版本。看看該行記錄中哪個版本對當前事務可見。
1. 該行記錄的最新版本為 trx12，與當前事務 read_view 進行對比發現，trx12 大于當前活躍事務列表中的最大事務 trx10，表示 trx12 是在當前事務創建之后才開啟的，因此不可見。
2. 再查看該行記錄的第二個最新版本為 trx7，與當前事務 read_view 對比發現，trx7 介于當前活躍事務列表最小事務 ID 和最大事務 ID 之間，表明該行記錄所在事務在當前事務創建的時候處于活動狀態，在活躍列表中遍歷發現 trx7 確實存在，說明該事務還沒有提交，所以對當前事務不可見。
3. 繼續查看該記錄的第三個最新版本 trx5，也介于當前活躍事務列表最小事務 ID 和最大事務 ID 之間，表明該行記錄所在事務在當前事務創建的時候處于活動狀態，但遍歷發現該版本并不在活躍事務列表中，說明 trx5 對應事務已經提交(注：事務提交時間與事務編號沒有任何關聯，有可能事務編號大的事務先提交，事務編號小的事務后提交)，因此 trx5 版本行記錄對當前事務可見，直接返回。
Read Committed(技術解讀：寫寫并發使用 X 鎖，讀寫并發使用 MVCC 避免臟讀)
上文介紹了 MySQL 中 MVCC 技術實現機制，但要明白 RC 隔離級別下事務可見性，還需要 get 一個核心點：RC 隔離級別下的事務在每次執行 select 時都會生成一個最新的 read_view 代替原有的 read_view。
如上圖所示，左側為 1 號事務，在不同時間點對 id= 1 的記錄分別查詢了三次。右側為 2 號事務，對 id= 1 的記錄進行了更新。更新前該記錄只有一個版本，更新好變成了兩個版本。
1 號事務在 RC 隔離級別下每次執行 select 請求都會生成一個最新的 read_view，前兩次查詢生成的全局事務活躍列表中包含 trx2，因此根據 MVCC 規定查到的記錄為老版本; 最后一次查詢的時間點位于 2 號事務提交之后，因此生成的全局活躍事務列表中不包含 trx2，此時在根據 MVCC 規定查到的記錄就是最新版本記錄。
Repeatable Read(技術解讀：寫寫并發使用 X 鎖，讀寫并發使用 MVCC 避免不可重復讀; 當前讀使用 Gap 鎖避免幻讀)
和 RC 模式不同，RR 模式下事務不會再每次執行 select 的時候生成最新的 read_view，而是在事務第一次 select 時就生成 read_view，后續不會再變更，直至當前事務結束。這樣可以有效避免不可重復讀，使得當前事務在整個事務過程中讀到的數據都保持一致。示意圖如下所示：
這個就很容易理解，三次查詢所使用的全局活躍事務列表都一樣，且都是第一次生成的 read_view，那之后查到的記錄必然和第一次查到的記錄一致。
RR 隔離級別能夠避免幻讀嗎?
如果對幻讀還不了解的話，可以參考該系列的第一篇文章。如下圖所示，1 號事務對針對 id 1 的過濾條件執行了三次查詢，2 號事務執行了一次插入，插入的記錄剛好符合 id 1 這個條件。可以看出來，三次查詢得到的數據是一致的，這個是由 RR 隔離級別的 MVCC 機制保證的。這么看來，是避免了幻讀，但是在最后 1 號事務在 id= 2 處插入一條記錄，MySQL 會返回 Duplicate entry 的錯誤，可見避免了幻讀是一種假象。
嚴格意義避免幻讀(技術解讀：當前讀使用 Gap 鎖避免幻讀)
之前提到的所有 RR 級別的 select 語句我們稱為快照讀，快照讀能夠保證不可重復讀，但并不能避免幻讀。于是 MySQL 又提出”當前讀”的概念，常見的當前讀語句有：
1. select for update
2. select lock in share mode
3. update / delete
并且規定，RR 級別下當前讀語句會給記錄加上一種特殊的鎖 -Gap 鎖，Gap 鎖并不鎖定某個具體的記錄，而是鎖定記錄與記錄之間的間隔，保證這個間隔中不會插入新的其他記錄。下圖是一個示意圖：
上圖中 1 號事務首先執行了一個當前讀的 select 語句，這個語句會在 id 0 的所有間隔加上 Gap 鎖，接下來 2 號事務在 id = 3 處執行插入時系統就會返回 Lock wait timeout execcded 的異常。當然，其他事務可以在 id = 0 的條件下插入成功，這沒問題。
Serializable (技術解讀：S 鎖(讀)+ X 鎖(寫))
Serialization 隔離級別是最嚴格的隔離級別，所有讀請求都會加上讀鎖，不分快照讀和當前讀，所有寫會加上寫鎖。當然，這種隔離級別的性能因為鎖開銷而相對最差。
MySQL 事務持久性保證
MySQL 事務持久化策略和 HBase 基本相同，但是涉及的組件相對比較多，主要有 doublewrite、redo log 以及 binlog：
1. MySQL 數據持久化(DoubleWrite)
實際上 MySQL 的真實數據寫入分為兩次寫入，一次寫入到一個稱為 DoubleWrite 的地方，寫成功之后再真實寫入數據所在磁盤。為什么要寫兩次? 這是因為 MySQL 數據頁大小與磁盤一次原子操作大小不一致，有可能會出現部分寫入的情況，比如默認 InnoDB 數據頁大小為 16K，而磁盤一次原子寫入大小為 512 字節(扇區大小)，這樣一個數據頁寫入需要多次 IO，這樣一旦中間發生異常就會出現數據丟失。另外需要注意的是 DoubleWrite 性能并不會影響太大，因為寫入 DoubleWrite 是順序寫入，對性能影響來說不是很大。
2. redolog 持久化策略(innodb_flush_log_at_trx_commit)
redolog 是 InnoDB 的 WAL，數據先寫入 redolog 并落盤，再寫入更新到 bufferpool。redolog 的持久化策略和 HBase 中 hlog 的持久化策略一致，默認為 1，表示每次事務提交之后 log 就會持久化到磁盤; 該值為 0 表示每隔 1 秒鐘左右由異步線程持久化到磁盤，這種情況下 MySQL 發生宕機有可能會丟失部分數據。該值為 2 表示每次事務提交之后 log 會 flush 到操作系統緩沖區，再由操作系統異步 flush 到磁盤，這種情況下 MySQL 發生宕機不會丟失數據，但機器宕機有可能會丟失部分數據。
3. binlog 持久化策略(sync_binlog)
binlog 作為 Server 層的日志系統，主要以 events 的形式順序紀錄了數據庫的各種操作，同時可以紀錄每次操作所花費的時間。在 MySQL 官方文檔上，主要介紹了 Binlog 的兩個最基本核心作用：備份和復制，因此 binlog 的持久化會一定程度影響數據備份和復制的完整性。和 redo 持久化策略相同，可取值有 0，1，N。默認為 0，表示寫入操作系統緩沖區，異步 flush 到磁盤。該值為 1 表示同步寫入磁盤。為 N 則表示每寫 N 次操作系統緩沖就執行一次刷新操作。
以上就是 MySQL 中怎么實現跨行事務模型，丸趣 TV 小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注丸趣 TV 行業資訊頻道。
