本篇文章給大家分享的是有關MySQL中怎么實現(xiàn)跨行事務模型，小編覺得挺實用的，因此分享給大家學習，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。

創(chuàng)新互聯(lián)建站-專業(yè)網(wǎng)站定制、快速模板網(wǎng)站建設、高性價比青秀網(wǎng)站開發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫,直接使用。一站式青秀網(wǎng)站制作公司更省心,省錢,快速模板網(wǎng)站建設找我們，業(yè)務覆蓋青秀地區(qū)。費用合理售后完善，10多年實體公司更值得信賴。

MySQL事務原子性保證

事務原子性要求事務中的一系列操作要么全部完成，要么不做任何操作，不能只做一半。原子性對于原子操作很容易實現(xiàn)，就像HBase中行級事務的原子性實現(xiàn)就比較簡單。但對于多條語句組成的事務來說，如果事務執(zhí)行過程中發(fā)生異常，需要保證原子性就只能回滾，回滾到事務開始前的狀態(tài)，就像這個事務根本沒有發(fā)生過一樣。如何實現(xiàn)呢?

MySQL實現(xiàn)回滾操作完全依賴于undo log，多說一句，undo  log在MySQL除了用來實現(xiàn)原子性保證之外，還用來實現(xiàn)MVCC，下文也會涉及到。使用undo實現(xiàn)原子性在操作任何數(shù)據(jù)之前，首先會將修改前的數(shù)據(jù)記錄到undo  log中，再進行實際修改。如果出現(xiàn)異常需要回滾，系統(tǒng)可以利用undo中的備份將數(shù)據(jù)恢復到事務開始之前的狀態(tài)。下圖是MySQL中表示事務的基本數(shù)據(jù)結構，其中與undo相關的字段為insert_undo和update_undo，分別指向本次事務所產生的undo  log。

事務回滾根據(jù)update_undo(或者insert_undo)找到對應的undo  log，做逆向操作即可。對于已經標記刪除的數(shù)據(jù)清理刪除標記，對于更新數(shù)據(jù)直接回滾更新;插入操作稍微復雜一些，不僅需要刪除數(shù)據(jù)，還需要刪除相關的聚集索引以及二級索引記錄。

undo log是MySQL內核中非常重要的一塊內容，涉及知識比較多而且復雜，比如：

1. undo log必須在數(shù)據(jù)修改之前持久化，undo log持久化需不需要記錄redo以防止宕機異常?如果需要就又涉及宕機恢復…

2. 通過undo log如何實現(xiàn)MVCC?

3. 那些undo log可以在什么場景下回收清理?如何清理?

MySQL事務一致性保證：強一致性事務保證

MySQL事務隔離級別

Read Uncommitted(RU技術解讀：使用X鎖實現(xiàn)寫寫并發(fā))

Read  Uncommitted只實現(xiàn)了寫寫并發(fā)控制，并沒有有效的讀寫并發(fā)控制，導致當前事務可能讀到其他事務中還未提交的修改數(shù)據(jù)，這些數(shù)據(jù)準確性并不靠譜(有可能被回滾掉)，因此在此基礎上作出的一切假設就都不靠譜的。在現(xiàn)實場景中很少有業(yè)務會選擇該隔離級別。

寫寫并發(fā)實現(xiàn)機制和HBase并無兩樣，都是使用兩階段鎖協(xié)議對相應記錄加行鎖實現(xiàn)。不過MySQL中行鎖機制比較復雜，根據(jù)行記錄是否是主鍵索引、唯一索引、非唯一索引或者無索引等分為多種加鎖情況。

1. 如果id列是主鍵索引，MySQL只會為聚簇索引記錄加鎖。

2. 如果id列是唯一二級索引，MySQL會為二級索引葉子節(jié)點以及聚簇索引記錄加鎖。

3. 如果id列是非唯一索引，MySQL會為所有滿足條件(id = 15)的二級索引葉子節(jié)點以及對應的聚簇索引記錄加鎖。

4. 如果id列是無索引的，SQL會走聚簇索引全表掃描，并將掃描結果加載到SQL  Server層進行過濾，因此InnoDB會為掃描過的所有記錄先加上鎖，如果SQL  Server層過濾不符合條件，InnoDB會釋放該鎖。因此InnoDB會為掃描到的所有記錄都加鎖，很恐怖吧!

接下來無論是RC、RR，抑或是Serialization，寫寫并發(fā)控制都使用上述機制，所以不再贅述。接下來會重點分析RC和RR隔離級別中的讀寫并發(fā)控制機制。

在詳細介紹RC和RR之前，有必要在此先行介紹MySQL中MVCC機制，因為RC和RR都使用MVCC機制實現(xiàn)事務之間的讀寫并發(fā)。只不過兩者在實現(xiàn)細節(jié)上有一些區(qū)別，具體區(qū)別接下來再聊。

MVCC in MySQL

MySQL中MVCC機制相比HBase來說要復雜的多，涉及的數(shù)據(jù)結構也比較復雜。為了解釋的比較清晰，以一個栗子為模版進行解釋。比如當前有一行記錄如下圖所示：

前面四列是該行記錄的實際列值，需要重點關注的是DB_TRX_ID和DB_ROLL_PTR兩個隱藏列(對用戶不可見)。其中DB_TRX_ID表示修改該行事務的事務ID，而DB_ROLL_PTR表示指向該行回滾段的指針，該行記錄上所有版本數(shù)據(jù)，在undo中都通過鏈表形式組織，該值實際指向undo中該行的歷史記錄鏈表。

現(xiàn)在假設有一個事務trx2修改了該行數(shù)據(jù)，該行記錄就會變?yōu)橄聢D形式，DB_TRX_ID為最近修改該行事務的事務ID(trx2)，DB_ROLL_PTR指向undo歷史紀錄鏈表：

了解了MySQL行記錄之后，再來看看事務的基本結構，下圖是MySQL的事務數(shù)據(jù)結構，上文我們提到過。事務在開啟之后會創(chuàng)建一個數(shù)據(jù)結構存儲事務相關信息、鎖信息、undo  log以及非常重要的read_view信息。

read_view保存了當前事務開啟時整個MySQL中所有活躍事務列表，如下圖所示，在當前事務開啟的時候，系統(tǒng)中活躍的事務有trx4、trx6、trx7以及trx10。另外，up_trx_id表示當前事務啟動時，當前事務鏈表中最小的事務ID;low_trx_id表示當前事務啟動時，當前事務鏈表中最大的事務ID。

read_view是實現(xiàn)MVCC的一個關鍵點，它用來判斷記錄的哪個版本對當前事務可見。如果當前事務要讀取某行記錄，該行記錄的版本號(事務ID)為trxid，那么：

1. 如果trxid < up_trx_id，說明該行記錄所在的事務已經在當前事務創(chuàng)建之前就提交了，所以該行記錄對當前事務可見。

2. 如果trxid > low_trx_id，說明該行事務所在的事務是在當前事務創(chuàng)建之后才開啟，所以該行記錄對當前事務不可見。

3. 如果up_trx_id < trxid < low_trx_id，  那么表明該行記錄所在事務在本次新事務創(chuàng)建的時候處于活動狀態(tài)。從up_trx_id到low_trx_id進行遍歷，如果trxid等于他們之中的某個事務id的話，那么不可見，否則可見。

以下面行記錄為例，該行記錄存在多個版本(trx2、trx5、trx7以及trx12)，其中trx12是最新版本?？纯丛撔杏涗浿心膫€版本對當前事務可見。

1.  該行記錄的最新版本為trx12，與當前事務read_view進行對比發(fā)現(xiàn)，trx12大于當前活躍事務列表中的最大事務trx10，表示trx12是在當前事務創(chuàng)建之后才開啟的，因此不可見。

2.  再查看該行記錄的第二個最新版本為trx7，與當前事務read_view對比發(fā)現(xiàn)，trx7介于當前活躍事務列表最小事務ID和最大事務ID之間，表明該行記錄所在事務在當前事務創(chuàng)建的時候處于活動狀態(tài)，在活躍列表中遍歷發(fā)現(xiàn)trx7確實存在，說明該事務還沒有提交，所以對當前事務不可見。

3.  繼續(xù)查看該記錄的第三個最新版本trx5，也介于當前活躍事務列表最小事務ID和最大事務ID之間，表明該行記錄所在事務在當前事務創(chuàng)建的時候處于活動狀態(tài)，但遍歷發(fā)現(xiàn)該版本并不在活躍事務列表中，說明trx5對應事務已經提交(注：事務提交時間與事務編號沒有任何關聯(lián)，有可能事務編號大的事務先提交，事務編號小的事務后提交)，因此trx5版本行記錄對當前事務可見，直接返回。

Read Committed(技術解讀：寫寫并發(fā)使用X鎖，讀寫并發(fā)使用MVCC避免臟讀)

上文介紹了MySQL中MVCC技術實現(xiàn)機制，但要明白RC隔離級別下事務可見性，還需要get一個核心點：RC隔離級別下的事務在每次執(zhí)行select時都會生成一個最新的read_view代替原有的read_view。

如上圖所示，左側為1號事務，在不同時間點對id=1的記錄分別查詢了三次。右側為2號事務，對id=1的記錄進行了更新。更新前該記錄只有一個版本，更新好變成了兩個版本。

1號事務在RC隔離級別下每次執(zhí)行select請求都會生成一個最新的read_view，前兩次查詢生成的全局事務活躍列表中包含trx2，因此根據(jù)MVCC規(guī)定查到的記錄為老版本;最后一次查詢的時間點位于2號事務提交之后，因此生成的全局活躍事務列表中不包含trx2，此時在根據(jù)MVCC規(guī)定查到的記錄就是最新版本記錄。

Repeatable Read(技術解讀：寫寫并發(fā)使用X鎖，讀寫并發(fā)使用MVCC避免不可重復讀;當前讀使用Gap鎖避免幻讀)

和RC模式不同，RR模式下事務不會再每次執(zhí)行select的時候生成最新的read_view，而是在事務第一次select時就生成read_view，后續(xù)不會再變更，直至當前事務結束。這樣可以有效避免不可重復讀，使得當前事務在整個事務過程中讀到的數(shù)據(jù)都保持一致。示意圖如下所示：

這個就很容易理解，三次查詢所使用的全局活躍事務列表都一樣，且都是第一次生成的read_view，那之后查到的記錄必然和第一次查到的記錄一致。

RR隔離級別能夠避免幻讀嗎?

如果對幻讀還不了解的話，可以參考該系列的第一篇文章。如下圖所示，1號事務對針對id>1的過濾條件執(zhí)行了三次查詢，2號事務執(zhí)行了一次插入，插入的記錄剛好符合id>1這個條件?？梢钥闯鰜恚尾樵兊玫降臄?shù)據(jù)是一致的，這個是由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

并且規(guī)定，RR級別下當前讀語句會給記錄加上一種特殊的鎖-Gap鎖，Gap鎖并不鎖定某個具體的記錄，而是鎖定記錄與記錄之間的間隔，保證這個間隔中不會插入新的其他記錄。下圖是一個示意圖：

上圖中1號事務首先執(zhí)行了一個當前讀的select語句，這個語句會在 id > 0的所有間隔加上Gap鎖，接下來2號事務在id =  3處執(zhí)行插入時系統(tǒng)就會返回Lock wait timeout execcded的異常。當然，其他事務可以在id <=  0的條件下插入成功，這沒問題。

Serializable (技術解讀：S鎖(讀)+X鎖(寫))

Serialization隔離級別是最嚴格的隔離級別，所有讀請求都會加上讀鎖，不分快照讀和當前讀，所有寫會加上寫鎖。當然，這種隔離級別的性能因為鎖開銷而相對最差。

MySQL事務持久性保證

MySQL事務持久化策略和HBase基本相同，但是涉及的組件相對比較多，主要有doublewrite、redo log以及binlog：

1. MySQL數(shù)據(jù)持久化(DoubleWrite)

實際上MySQL的真實數(shù)據(jù)寫入分為兩次寫入，一次寫入到一個稱為DoubleWrite的地方，寫成功之后再真實寫入數(shù)據(jù)所在磁盤。為什么要寫兩次?這是因為MySQL數(shù)據(jù)頁大小與磁盤一次原子操作大小不一致，有可能會出現(xiàn)部分寫入的情況，比如默認InnoDB數(shù)據(jù)頁大小為16K，而磁盤一次原子寫入大小為512字節(jié)(扇區(qū)大小)，這樣一個數(shù)據(jù)頁寫入需要多次IO，這樣一旦中間發(fā)生異常就會出現(xiàn)數(shù)據(jù)丟失。另外需要注意的是DoubleWrite性能并不會影響太大，因為寫入DoubleWrite是順序寫入，對性能影響來說不是很大。

2. redolog持久化策略(innodb_flush_log_at_trx_commit)

redolog是InnoDB的WAL，數(shù)據(jù)先寫入redolog并落盤，再寫入更新到bufferpool。redolog的持久化策略和HBase中hlog的持久化策略一致，默認為1，表示每次事務提交之后log就會持久化到磁盤;該值為0表示每隔1秒鐘左右由異步線程持久化到磁盤，這種情況下MySQL發(fā)生宕機有可能會丟失部分數(shù)據(jù)。該值為2表示每次事務提交之后log會flush到操作系統(tǒng)緩沖區(qū)，再由操作系統(tǒng)異步flush到磁盤，這種情況下MySQL發(fā)生宕機不會丟失數(shù)據(jù)，但機器宕機有可能會丟失部分數(shù)據(jù)。

3. binlog持久化策略(sync_binlog)

binlog作為Server層的日志系統(tǒng)，主要以events的形式順序紀錄了數(shù)據(jù)庫的各種操作，同時可以紀錄每次操作所花費的時間。在MySQL官方文檔上，主要介紹了Binlog的兩個最基本核心作用：備份和復制，因此binlog的持久化會一定程度影響數(shù)據(jù)備份和復制的完整性。和redo持久化策略相同，可取值有0，1，N。默認為0，表示寫入操作系統(tǒng)緩沖區(qū)，異步flush到磁盤。該值為1表示同步寫入磁盤。為N則表示每寫N次操作系統(tǒng)緩沖就執(zhí)行一次刷新操作。

以上就是MySQL中怎么實現(xiàn)跨行事務模型，小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注創(chuàng)新互聯(lián)行業(yè)資訊頻道。

網(wǎng)站名稱：MySQL中怎么實現(xiàn)跨行事務模型
網(wǎng)頁URL：http://jinyejixie.com/article42/ghoiec.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供定制網(wǎng)站、小程序開發(fā)、網(wǎng)頁設計公司、網(wǎng)站導航、自適應網(wǎng)站、企業(yè)網(wǎng)站制作

廣告

聲明：本網(wǎng)站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)