MySQL保證數(shù)據(jù)一致性的方式

這篇文章主要講解了“MySQL保證數(shù)據(jù)一致性的方式”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“MySQL保證數(shù)據(jù)一致性的方式”吧！

創(chuàng)新互聯(lián)專注于企業(yè)全網(wǎng)營銷推廣、網(wǎng)站重做改版、濂溪網(wǎng)站定制設(shè)計、自適應(yīng)品牌網(wǎng)站建設(shè)、html5、商城建設(shè)、集團公司官網(wǎng)建設(shè)、外貿(mào)網(wǎng)站制作、高端網(wǎng)站制作、響應(yīng)式網(wǎng)頁設(shè)計等建站業(yè)務(wù)，價格優(yōu)惠性價比高，為濂溪等各大城市提供網(wǎng)站開發(fā)制作服務(wù)。

一、MySQL事務(wù)模型ACID

MySQL是一個多引擎數(shù)據(jù)庫，其中InnoDB支持數(shù)據(jù)庫事務(wù)，也是最常用的引擎。下邊就介紹InnoDB的事務(wù)模型

MySQL官方文檔對事務(wù)是這么描述的“事務(wù)是可以提交或回滾的原子工作單元。當(dāng)事務(wù)對數(shù)據(jù)庫進行多個更改時，要么提交事務(wù)時所有更改都成功，要么回滾事務(wù)時撤消所有更改。”

“ACID模型是一組數(shù)據(jù)庫設(shè)計原則，強調(diào)業(yè)務(wù)數(shù)據(jù)和關(guān)鍵應(yīng)用程序的可靠性很重要。MySQL包含與ACID模型緊密結(jié)合的innodb存儲引擎組件，確保數(shù)據(jù)不會被破壞，結(jié)果不會被軟件崩潰和硬件故障等異常情況所篡改。當(dāng)您依賴ACID的特性，就不再需要重新發(fā)明一致性檢查和崩潰恢復(fù)機制?！?/p>

ACID模型按照字母拆解分為四大特性

A : atomicity 原子性。原子性是我們對事務(wù)最直觀的理解：事務(wù)就是一系列的操作，要么全部都執(zhí)行，要么全部都不執(zhí)行。

C : consistency 一致性。數(shù)據(jù)庫事務(wù)不能破壞關(guān)系數(shù)據(jù)的完整性以及業(yè)務(wù)邏輯上的一致性。例如對銀行轉(zhuǎn)帳事務(wù)，不管事務(wù)成功還是失敗，應(yīng)該保證事務(wù)結(jié)束后ACCOUNTS表中Tom和Jack的存款和不變。

I : isolation 隔離性。在并發(fā)環(huán)境中，當(dāng)不同的事務(wù)同時操縱相同的數(shù)據(jù)時，每個事務(wù)都有各自的完整數(shù)據(jù)空間。

D : durability 持久性。只要事務(wù)成功結(jié)束，它對數(shù)據(jù)庫所做的更新就必須永久保存下來。即使發(fā)生系統(tǒng)崩潰，重新啟動數(shù)據(jù)庫系統(tǒng)后，數(shù)據(jù)庫還能恢復(fù)到事務(wù)成功結(jié)束時的狀態(tài)。

二、InnoDB存儲引擎架構(gòu)

下邊這張圖是InnoDB的架構(gòu)，包括兩大部分，內(nèi)存結(jié)構(gòu)（In-Memory Structures）和磁盤上的結(jié)構(gòu)（On-Disk Structures）。

在這張圖中，尤其要關(guān)注“Redo Log”和“Undo Tablespaces”這兩個區(qū)域，它們跟事務(wù)息息相關(guān)。 

內(nèi)存結(jié)構(gòu)（In-Memory Structures）更多的目的是在提高性能，因此本文不會過多關(guān)注。如果感興趣，可以訪問MySQL的官方網(wǎng)站www.mysql.com

“Undo Tablespaces”包含Undo Log（撤消日志），Undo Log是撤消日志記錄的集合，其中包含如何撤消事務(wù)對聚集索引記錄的最新更改的信息。Undo Log存在于撤消日志段中，這些日志段包含在回滾段中。

MySQL事務(wù)的四個特性中ACD三個特性是通過Redo Log（重做日志）和Undo Log 實現(xiàn)的，而 I（隔離性）是通過Lock（鎖）來實現(xiàn)。

三、普及個概念MVCC

MVCC，Multi-Version Concurrency Control，多版本并發(fā)控制。這項技術(shù)使得InnoDB的事務(wù)隔離級別下執(zhí)行一致性讀操作有了保證，換言之，就是為了查詢一些正在被另一個事務(wù)更新的行，并且可以看到它們被更新之前的值。這是一個可以用來增強并發(fā)性的強大技術(shù)，查詢不用等待另一個事務(wù)釋放鎖。這項技術(shù)廣泛應(yīng)用于數(shù)據(jù)庫，例如Oracle，PostgreSQL。當(dāng)然也有一些數(shù)據(jù)庫產(chǎn)品以及mysql的其它存儲引擎不支持它。

看一看MVCC機制的示意圖，圖下邊會給出文字解釋 

圖中底部橫軸是時間，縱向的箭頭用來標(biāo)記增、刪、改、查發(fā)生的時刻。尤其注意時間軸上方兩條色塊，代表數(shù)據(jù)的兩個版本V1、V2。為了醒目，我把V1、V2用紅色方框圈了起來（多版本的體現(xiàn)）。從左向右解讀這張圖

1、T1事務(wù)插入數(shù)據(jù)a=3，然后提交，生成了數(shù)據(jù)對應(yīng)的V1版本

2、T2事務(wù)開始讀取a數(shù)據(jù)，讀取會持續(xù)一段時間，由于開始讀取的時刻，只有V1版本，所以最終T2讀到a=3

3、T2讀取過程中，T3對數(shù)據(jù)a進行修改，a=4，生成a數(shù)據(jù)的V2版本，但此時并未提交，因此生效的是V1版本數(shù)據(jù)。

4、T3修改提交之前，T4讀取a數(shù)據(jù)，由于此時V1版本數(shù)據(jù)生效，因此，T4讀到a=3

5、T3提交a=4的修改，V1版本數(shù)據(jù)失效，V2生效。a的值變?yōu)?

6、T5讀取a的值，讀到V2版本，a=4

至此，MVCC的概念就搞明白了，那么MySQL是怎么實現(xiàn)的呢？

四、InnoDB多版本的實現(xiàn)

1、三個隱藏字段

在內(nèi)部，InnoDB向數(shù)據(jù)庫中存儲的每一行數(shù)據(jù)添加三個字段。

（1）DB_TRX_ID字段，6字節(jié)。表示插入或更新行的最后一個事務(wù)的事務(wù)標(biāo)識符。此外，刪除在內(nèi)部被視為更新，其中行中的特殊位被設(shè)置為將其標(biāo)記為已刪除。

（2）DB_ROLL_PTR字段，7字節(jié)，叫做回滾指針（roll pointer）?；貪L指針指向?qū)懭牖貪L段的撤消日志（Undo Log）。如果行已更新，則撤消日志包含重建更新前該行內(nèi)容所需的信息。

（3）DB_ROW_ID字段，6字節(jié)。包含一個隨著新行插入而單調(diào)增加的行ID，如果innodb自動生成聚集索引，則該索引包含行ID值。否則，DB_ROW_ID列不會出現(xiàn)在任何索引中。

2、多版本產(chǎn)生過程

以新增一條記錄并對該記錄進行2次修改來說明具體實現(xiàn) 

這條記錄有3個隱含字段（前面已經(jīng)介紹），分別應(yīng)對行的ID、事務(wù)號和回滾指針。

當(dāng)插入的是一條新數(shù)據(jù)時，記錄上對應(yīng)的回滾段指針為NULL 

這個過程做了以下幾件事

• 用排他鎖鎖定該行

• 把該行修改前的值拷貝到Undo Log中

• 修改當(dāng)前行的值，填寫事務(wù)編號，使回滾指針指向Undo Log中的修改前的行

• 記錄Redo Log，包括Undo Log中的變化 

多次更新后，回滾指針會把不同版本的記錄串在一起。在InnoDB中存在purge線程，它會查詢那些比現(xiàn)在最老的活動事務(wù)還早的Undo Log，并刪除它們，從而保證Undo Log文件不至于無限增長。

3、提交與回滾

當(dāng)事務(wù)正常提交時，InnoDB只需要更改事務(wù)狀態(tài)為commit即可，不需要做其他額外的工作

回滾（rollback）需要根據(jù)當(dāng)前回滾指針從Undo Log中找出事務(wù)修改前的版本，并恢復(fù)。如果事務(wù)影響的行非常多，回滾則可能會很慢，根據(jù)經(jīng)驗值沒提交的事務(wù)行數(shù)在1000~10000之間，InnoDB效率還是非常高的（唐成-數(shù)據(jù)庫多版本實現(xiàn)內(nèi)幕）。

commit效率高，rollback代價大

4、可見性

事務(wù)隔離是數(shù)據(jù)庫處理的基礎(chǔ)之一，隔離是縮寫ACID中的I。隔離級別是當(dāng)多個事務(wù)同時進行更改和執(zhí)行查詢時，微調(diào)性能、可靠性、一致性和結(jié)果再現(xiàn)性之間的平衡的設(shè)置。

InnoDB提供SQL1992標(biāo)準定義的四個隔離級別，READ UNCOMMITTED（未提交讀）, READ COMMITTED（已提交讀）, REPEATABLE READ（可重復(fù)讀）, and SERIALIZABLE（可串行化）。默認的是REPEATABLE READ

每種隔離級別具體的意義可以百度查到，實現(xiàn)原理深入進去比較復(fù)雜。注意到每條數(shù)據(jù)隱藏的事務(wù)ID字段DB_TRX_ID有時序性，理論上可以根據(jù)一些策略，借助這個字段來實現(xiàn)與隔離級別相關(guān)的功能。事實上InnoDB也是這么做的。當(dāng)然這個功能還涉及很多鎖的問題，這里不再展開。

MySQL官方文檔在“鎖和事務(wù)模型”這一章節(jié)開始就介紹了InnoDB的鎖，截個目錄，感興趣可以去讀一下。 

感謝各位的閱讀，以上就是“MySQL保證數(shù)據(jù)一致性的方式”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對MySQL保證數(shù)據(jù)一致性的方式這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是創(chuàng)新互聯(lián)，小編將為大家推送更多相關(guān)知識點的文章，歡迎關(guān)注！

名稱欄目：MySQL保證數(shù)據(jù)一致性的方式
網(wǎng)站URL：http://muchs.cn/article8/ispsop.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站維護、網(wǎng)站導(dǎo)航、靜態(tài)網(wǎng)站、網(wǎng)站營銷、面包屑導(dǎo)航、營銷型網(wǎng)站建設(shè)

廣告

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