MySQL中怎么實(shí)現(xiàn)跨行事務(wù)模型

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

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

MySQL事務(wù)原子性保證

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

MySQL實(shí)現(xiàn)回滾操作完全依賴于undo log，多說(shuō)一句，undo  log在MySQL除了用來(lái)實(shí)現(xiàn)原子性保證之外，還用來(lái)實(shí)現(xiàn)MVCC，下文也會(huì)涉及到。使用undo實(shí)現(xiàn)原子性在操作任何數(shù)據(jù)之前，首先會(huì)將修改前的數(shù)據(jù)記錄到undo  log中，再進(jìn)行實(shí)際修改。如果出現(xiàn)異常需要回滾，系統(tǒng)可以利用undo中的備份將數(shù)據(jù)恢復(fù)到事務(wù)開(kāi)始之前的狀態(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)找到對(duì)應(yīng)的undo  log，做逆向操作即可。對(duì)于已經(jīng)標(biāo)記刪除的數(shù)據(jù)清理刪除標(biāo)記，對(duì)于更新數(shù)據(jù)直接回滾更新;插入操作稍微復(fù)雜一些，不僅需要?jiǎng)h除數(shù)據(jù)，還需要?jiǎng)h除相關(guān)的聚集索引以及二級(jí)索引記錄。

undo log是MySQL內(nèi)核中非常重要的一塊內(nèi)容，涉及知識(shí)比較多而且復(fù)雜，比如：

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

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

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

MySQL事務(wù)一致性保證：強(qiáng)一致性事務(wù)保證

MySQL事務(wù)隔離級(jí)別

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

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

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

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

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

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

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

接下來(lái)無(wú)論是RC、RR，抑或是Serialization，寫(xiě)寫(xiě)并發(fā)控制都使用上述機(jī)制，所以不再贅述。接下來(lái)會(huì)重點(diǎn)分析RC和RR隔離級(jí)別中的讀寫(xiě)并發(fā)控制機(jī)制。

在詳細(xì)介紹RC和RR之前，有必要在此先行介紹MySQL中MVCC機(jī)制，因?yàn)镽C和RR都使用MVCC機(jī)制實(shí)現(xiàn)事務(wù)之間的讀寫(xiě)并發(fā)。只不過(guò)兩者在實(shí)現(xiàn)細(xì)節(jié)上有一些區(qū)別，具體區(qū)別接下來(lái)再聊。

MVCC in MySQL

MySQL中MVCC機(jī)制相比HBase來(lái)說(shuō)要復(fù)雜的多，涉及的數(shù)據(jù)結(jié)構(gòu)也比較復(fù)雜。為了解釋的比較清晰，以一個(gè)栗子為模版進(jìn)行解釋。比如當(dāng)前有一行記錄如下圖所示：

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

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

了解了MySQL行記錄之后，再來(lái)看看事務(wù)的基本結(jié)構(gòu)，下圖是MySQL的事務(wù)數(shù)據(jù)結(jié)構(gòu)，上文我們提到過(guò)。事務(wù)在開(kāi)啟之后會(huì)創(chuàng)建一個(gè)數(shù)據(jù)結(jié)構(gòu)存儲(chǔ)事務(wù)相關(guān)信息、鎖信息、undo  log以及非常重要的read_view信息。

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

read_view是實(shí)現(xiàn)MVCC的一個(gè)關(guān)鍵點(diǎn)，它用來(lái)判斷記錄的哪個(gè)版本對(duì)當(dāng)前事務(wù)可見(jiàn)。如果當(dāng)前事務(wù)要讀取某行記錄，該行記錄的版本號(hào)(事務(wù)ID)為trxid，那么：

1. 如果trxid < up_trx_id，說(shuō)明該行記錄所在的事務(wù)已經(jīng)在當(dāng)前事務(wù)創(chuàng)建之前就提交了，所以該行記錄對(duì)當(dāng)前事務(wù)可見(jiàn)。

2. 如果trxid > low_trx_id，說(shuō)明該行事務(wù)所在的事務(wù)是在當(dāng)前事務(wù)創(chuàng)建之后才開(kāi)啟，所以該行記錄對(duì)當(dāng)前事務(wù)不可見(jiàn)。

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

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

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

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

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

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

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

如上圖所示，左側(cè)為1號(hào)事務(wù)，在不同時(shí)間點(diǎn)對(duì)id=1的記錄分別查詢了三次。右側(cè)為2號(hào)事務(wù)，對(duì)id=1的記錄進(jìn)行了更新。更新前該記錄只有一個(gè)版本，更新好變成了兩個(gè)版本。

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

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

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

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

RR隔離級(jí)別能夠避免幻讀嗎?

如果對(duì)幻讀還不了解的話，可以參考該系列的第一篇文章。如下圖所示，1號(hào)事務(wù)對(duì)針對(duì)id>1的過(guò)濾條件執(zhí)行了三次查詢，2號(hào)事務(wù)執(zhí)行了一次插入，插入的記錄剛好符合id>1這個(gè)條件?？梢钥闯鰜?lái)，三次查詢得到的數(shù)據(jù)是一致的，這個(gè)是由RR隔離級(jí)別的MVCC機(jī)制保證的。這么看來(lái)，是避免了幻讀，但是在最后1號(hào)事務(wù)在id=2處插入一條記錄，MySQL會(huì)返回Duplicate  entry的錯(cuò)誤，可見(jiàn)避免了幻讀是一種假象。

嚴(yán)格意義避免幻讀(技術(shù)解讀：當(dāng)前讀使用Gap鎖避免幻讀)

之前提到的所有RR級(jí)別的select語(yǔ)句我們稱為快照讀，快照讀能夠保證不可重復(fù)讀，但并不能避免幻讀。于是MySQL又提出”當(dāng)前讀”的概念，常見(jiàn)的當(dāng)前讀語(yǔ)句有：

1. select for update

2. select lock in share mode

3. update / delete

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

上圖中1號(hào)事務(wù)首先執(zhí)行了一個(gè)當(dāng)前讀的select語(yǔ)句，這個(gè)語(yǔ)句會(huì)在 id > 0的所有間隔加上Gap鎖，接下來(lái)2號(hào)事務(wù)在id =  3處執(zhí)行插入時(shí)系統(tǒng)就會(huì)返回Lock wait timeout execcded的異常。當(dāng)然，其他事務(wù)可以在id <=  0的條件下插入成功，這沒(méi)問(wèn)題。

Serializable (技術(shù)解讀：S鎖(讀)+X鎖(寫(xiě)))

Serialization隔離級(jí)別是最嚴(yán)格的隔離級(jí)別，所有讀請(qǐng)求都會(huì)加上讀鎖，不分快照讀和當(dāng)前讀，所有寫(xiě)會(huì)加上寫(xiě)鎖。當(dāng)然，這種隔離級(jí)別的性能因?yàn)殒i開(kāi)銷而相對(duì)最差。

MySQL事務(wù)持久性保證

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

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

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

2. redolog持久化策略(innodb_flush_log_at_trx_commit)

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

3. binlog持久化策略(sync_binlog)

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

以上就是MySQL中怎么實(shí)現(xiàn)跨行事務(wù)模型，小編相信有部分知識(shí)點(diǎn)可能是我們?nèi)粘９ぷ鲿?huì)見(jiàn)到或用到的。希望你能通過(guò)這篇文章學(xué)到更多知識(shí)。更多詳情敬請(qǐng)關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。

網(wǎng)站名稱：MySQL中怎么實(shí)現(xiàn)跨行事務(wù)模型
網(wǎng)頁(yè)URL：http://www.muchs.cn/article42/ghoiec.html

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

廣告

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