下文給大家?guī)碛嘘PMySQL數(shù)據(jù)庫的事務隔離和MVCC內(nèi)容，相信大家一定看過類似的文章。我們給大家?guī)淼挠泻尾煌兀恳黄饋砜纯凑牟糠职?，相信看完MySQL數(shù)據(jù)庫的事務隔離和MVCC你一定會有所收獲。

我們提供的服務有：網(wǎng)站設計、成都做網(wǎng)站、微信公眾號開發(fā)、網(wǎng)站優(yōu)化、網(wǎng)站認證、鄆城ssl等。為近1000家企事業(yè)單位解決了網(wǎng)站和推廣的問題。提供周到的售前咨詢和貼心的售后服務，是有科學管理、有技術的鄆城網(wǎng)站制作公司

1. 什么是事務?

事務必須服從ISO/IEC所制定的ACID原則。ACID是原子性（atomicity）、一致性（consistency）、隔離性（isolation）、持久性（durability）的縮寫，這四種狀態(tài)的意思是：
1.原子性（Atomicity）
原子性是指事務包含的所有操作要么全部成功，要么全部失敗回滾，這和前面兩篇博客介紹事務的功能是一樣的概念，因此事務的操作如果成功就必須要完全應用到數(shù)據(jù)庫，如果操作失敗則不能對數(shù)據(jù)庫有任何影響。
2.一致性（Consistency）
一致性是指事務必須使數(shù)據(jù)庫從一個一致性狀態(tài)變換到另一個一致性狀態(tài).
3.隔離性（Isolation）
在事務正確提交之前，不允許把事務對該數(shù)據(jù)的改變提供給任何其他事務，即在事務正確提交之前，它可能的結(jié)果不應該顯示給其他事務.
4.持久性（Durability）
持久性是指一個事務一旦被提交了，那么對數(shù)據(jù)庫中的數(shù)據(jù)的改變就是永久性的，即便是在數(shù)據(jù)庫系統(tǒng)遇到故障的情況下也不會丟失提交事務的操作。

2. 事務的作用

當多個線程都開啟事務操作數(shù)據(jù)庫中的數(shù)據(jù)時，數(shù)據(jù)庫系統(tǒng)要能進行隔離操作，以保證各個線程獲取數(shù)據(jù)的準確性.

3. 遇到的并發(fā)問題

1.第一類丟失更新:A事務撤銷時，把已經(jīng)提交的B事務的更新數(shù)據(jù)覆蓋了.
2.第二類丟失更新:A事務覆蓋B事務已經(jīng)提交的數(shù)據(jù)，造成B事務所做操作丟失.
3.臟讀:A事務讀取了事務B中未提交的數(shù)據(jù).
4.不可重復讀:A事務多次讀取的值不同,因為該值被B事務修改并提交了.
5.幻讀:A事務兩次讀之間,B事務插入了數(shù)據(jù).

4. 如何解決上面的問題呢?

為了解決上面的問題,開發(fā)者為MySQL數(shù)據(jù)庫設計了以下四種事務隔離級別:
1.Read Uncommitted(未提交讀)：允許臟讀，也就是可能讀取到其他會話中未提交事務修改的數(shù)據(jù).

2.Read Committed(提交讀)：只能讀取到已經(jīng)提交的數(shù)據(jù)。Oracle等多數(shù)數(shù)據(jù)庫默認都是該級別 (不重復讀).

3.Repeated Read(可重復讀)：可重復讀。在同一個事務內(nèi)的查詢都是事務開始時刻一致的，InnoDB默認級別。在SQL標準中，該隔離級別消除了不可重復讀，但是還存在幻象讀，但是innoDB解決了幻讀.

4.Serializable(串行讀)：完全串行化的讀，每次讀都需要獲得表級共享鎖，讀寫相互都會阻塞.

隔離級別	臟讀	不可重復度	不幻讀
Read Uncommitted(未提交讀)	可能	可能	可能
Read Committed(提交讀)	不可能	可能	可能
Repeated Read(可重復讀)	不可能	不可能	可能
Serializable(串行讀)	不可能	不可能	不可能

5. 小嘗試

1.查看全局或會話的事務隔離級別

SELECT @@global.tx_isolation, @@tx_isolation;

2.修改全局或會話的事務隔離級別

SET [SESSION|GLOBAL] TRANSACTION ISOLATION LEVEL [READ UNCOMMITTED|READ COMMITTED|REPEATABLE READ|SERIALIZABLE]

6. MySQL默認Repeated Read隔離級別,按道理并不能解決幻讀問題呀?

以下將先介紹數(shù)據(jù)庫所涉及的鎖.

7. 鎖的基本敘述

1.鎖簡介
數(shù)據(jù)庫中的鎖是指一種軟件機制，用來控制防止某個用戶（進程會話）在已經(jīng)占用了某種數(shù)據(jù)資源時，其他用戶做出影響本用戶數(shù)據(jù)操作或?qū)е聰?shù)據(jù)非完整性和非一致性問題發(fā)生的手段。
2.鎖的級別
按照鎖級別劃分，鎖可分為共享鎖、排他鎖。

• 共享鎖（讀鎖)

針對同一塊數(shù)據(jù)，多個讀操作可以同時進行而不會互相影響。共享鎖只針對UPDATE時候加鎖，在未對UPDATE操作提交之前，其他事務只能夠獲取最新的記錄但不能夠UPDATE操作。

• 排他鎖（寫鎖)

當前寫操作沒有完成前，阻斷其他寫鎖和讀鎖。
3.鎖的粒度
按鎖的粒度劃分，鎖可分為表級鎖、行級鎖、頁級鎖。

• 行級鎖

開銷大，加鎖慢，會出現(xiàn)死鎖，鎖定力度最小，發(fā)生鎖沖突的概率最低，并發(fā)度高。

• 表級鎖

開銷小，加鎖快，不會出現(xiàn)死鎖，鎖定力度大，發(fā)生沖突所的概率高，并發(fā)度低。

• 頁面鎖

開銷和加鎖時間介于表鎖和行鎖之間，會出現(xiàn)死鎖，鎖定力度介于表和行行級鎖之間，并發(fā)度一般。

8. 悲觀鎖和樂觀鎖

8.1 悲觀鎖

1.基本思想:總是假設最壞的情況，每次去拿數(shù)據(jù)的時候都認為別人會修改，所以每次在拿數(shù)據(jù)的時候都會上鎖，這樣別人想拿這個數(shù)據(jù)就會阻塞直到它拿到鎖（共享資源每次只給一個線程使用，其它線程阻塞，用完后再把資源轉(zhuǎn)讓給其它線程）。傳統(tǒng)的關系型數(shù)據(jù)庫里邊就用到了很多這種鎖機制，比如行鎖，表鎖等，讀鎖，寫鎖等，都是在做操作之前先上鎖.所以不管沖突是否真的發(fā)生，都會使用鎖機制。
2.悲觀鎖功能：

• 鎖住讀取的記錄，防止其它事務讀取和更新這些記錄。其它事務會一直阻塞，直到這個事務結(jié)束。
• 悲觀鎖是在使用了數(shù)據(jù)庫的事務隔離功能的基礎上，獨享占用的資源，以此保證讀取數(shù)據(jù)一致性，避免修改丟失。
• 悲觀鎖可以使用Repeatable Read事務，它完全滿足悲觀鎖的要求。

8.2 樂觀鎖

1.基本思想:總是假設最好的情況，每次去拿數(shù)據(jù)的時候都認為別人不會修改，所以不會上鎖，但是在更新的時候會判斷一下在此期間別人有沒有去更新這個數(shù)據(jù)，可以使用版本號機制和CAS算法實現(xiàn)。樂觀鎖適用于多讀的應用類型，這樣可以提高吞吐量.
2.解釋:樂觀鎖是一種思想,樂觀鎖不會鎖住任何東西，也就是說，它不依賴數(shù)據(jù)庫的事務機制，樂觀鎖完全是應用系統(tǒng)層面的東西。所以它不是一種鎖機制.如果使用樂觀鎖，那么數(shù)據(jù)庫就必須加版本字段，否則就只能比較所有字段，但因為浮點類型不能比較，所以實際上沒有版本字段是不可行的

8.3 版本號機制

一般是在數(shù)據(jù)表中加上一個數(shù)據(jù)版本號version字段，表示數(shù)據(jù)被修改的次數(shù)，當數(shù)據(jù)被修改時，version值會加一。當線程A要更新數(shù)據(jù)值時，在讀取數(shù)據(jù)的同時也會讀取version值，在提交更新時，若剛才讀取到的version值為當前數(shù)據(jù)庫中的version值相等時才更新，否則重試更新操作，直到更新成功。

8.4 CAS算法

1.核心思想:Compare and Swap，即比較再交換。
2.過程:假設有A線程準備去修改內(nèi)存中變量名為name的值,因此A線程會用以前自己讀到的name變量值和此刻name的值做對比,如果一樣,則表明在變量值沒被修改過,因此可以更新修改,否則更新失敗.

9. 回到MySQL的重復讀(Repeated Read)事務隔離級別

前面說過,MySQL默認實現(xiàn)了可重復讀的事務隔離級別,但是不能解決幻讀的問題,然而在MySQL數(shù)據(jù)庫使用可重復讀的事務隔離條件下,并未發(fā)生幻讀.MySQL使用MVCC(多版本并發(fā)控制)進行了控制.

9.1名詞簡析:

1.MVCC:是multiversion concurrency control的簡稱，也就是多版本并發(fā)控制，是個很基本的概念。MVCC的作用是讓事務在并行發(fā)生時，在一定隔離級別前提下，可以保證在某個事務中能實現(xiàn)一致性讀，也就是該事務啟動時根據(jù)某個條件讀取到的數(shù)據(jù)，直到事務結(jié)束時，再次執(zhí)行相同條件，還是讀到同一份數(shù)據(jù)，不會發(fā)生變化（不會看到被其他并行事務修改的數(shù)據(jù)）。
2.read view:InnoDB MVCC使用的內(nèi)部快照的意思。在不同的隔離級別下，事務啟動時（有些情況下，可能是SQL語句開始時）看到的數(shù)據(jù)快照版本可能也不同。在上面介紹的幾個隔離級別下會用到 read view。
3.快照讀: 就是所謂的根據(jù)read view去獲取信息和數(shù)據(jù)，不會加任何的鎖。
4.當前讀:前讀會獲取得到所有已經(jīng)提交數(shù)據(jù)，按照邏輯上來講的話，在一個事務中第一次當前讀和第二次當前讀的中間有新的事務進行DML操作，這個時候倆次當前讀的結(jié)果應該是不一致的，但是實際的情況卻是在當前讀的這個事務還沒提交之前，所有針對當前讀的數(shù)據(jù)修改和插入都會被阻塞，主要是因為next-key lock解決了當前讀可能會發(fā)生幻讀的情況。
next-key lock當使用主鍵索引進行當前讀的時候，會降級為record lock(行鎖)

9.2 Read view詳析

InnoDB支持MVCC多版本控制，其中READ COMMITTED和REPEATABLE READ隔離級別是利用consistent read view(一致讀視圖)方式支持的。所謂的consistent read view就是在某一時刻給事務系統(tǒng)trx_sys打snapshot(快照)，把當時的trx_sys狀態(tài)(包括活躍讀寫事務數(shù)組)記下來，之后的所有讀操作根據(jù)其事務ID(即trx_id)與snapshot中trx_sys的狀態(tài)做比較，以此判斷read view對事務的可見性。
REPEATABLE READ隔離級別(除了GAP鎖之外)和READ COMMITTED隔離級別的差別是創(chuàng)建snapshot時機不同。REPEATABLE READ隔離級別是在事務開始時刻，確切的說是第一個讀操作創(chuàng)建read view的時候,READ COMMITTED隔離級別是在語句開始時刻創(chuàng)建read view的。這就意味著REPEATABLE READ隔離級別下面一個事務的SELECT操作只會獲取一個read view，但是READ COMMITTED隔離級別下一個事務是可以獲取多個read view的。
創(chuàng)建／關閉read view需要持有trx_sys->mutex，會降低系統(tǒng)性能，5.7版本對此進行優(yōu)化，在事務提交時session會cache只讀事務的read view。

9.3 read view 判斷當前版本數(shù)據(jù)項是否可見

在InnoDB中，創(chuàng)建一個新事務的時候，InnoDB會將當前系統(tǒng)中的活躍事務列表（trx_sys->trx_list）創(chuàng)建一個副本（read view），副本中保存的是系統(tǒng)當前不應該被本事務看到的其他事務id列表。當用戶在這個事務中要讀取該行記錄的時候，InnoDB會將該行當前的版本號與該read view進行比較。
具體的算法如下:
設該行的當前事務id為trx_id，read view中最早的事務id為trx_id_min, 最遲的事務id為trx_id_max。
如果trx_id< trx_id_min的話，那么表明該行記錄所在的事務已經(jīng)在本次新事務創(chuàng)建之前就提交了，所以該行記錄的當前值是可見的。
如果trx_id>trx_id_max的話，那么表明該行記錄所在的事務在本次新事務創(chuàng)建之后才開啟，所以該行記錄的當前值不可見。
如果trx_id_min <= trx_id <= trx_id_max, 那么表明該行記錄所在事務在本次新事務創(chuàng)建的時候處于活動狀態(tài)，從trx_id_min到trx_id_max進行遍歷，如果trx_id等于他們之中的某個事務id的話，那么不可見,如圖：

從該行記錄的DB_ROLL_PTR指針所指向的回滾段中取出最新的undo-log的版本號的數(shù)據(jù)，將該可見行的值返回。
需要注意的是，新建事務(當前事務)與正在內(nèi)存中commit 的事務不在活躍事務鏈表中。
在具體多版本控制中我們先來看下源碼：

函數(shù)：read_view_sees_trx_id。
read_view中保存了當前全局的事務的范圍：
【low_limit_id， up_limit_id】

1.當行記錄的事務ID小于當前系統(tǒng)的最小活動id，就是可見的。
    　　if (trx_id < view->up_limit_id) {
        　　　　return(TRUE);
        　　}
2.當行記錄的事務ID大于當前系統(tǒng)的大活動id（也就是尚未分配的下一個事務的id），就是不可見的。
    　　if (trx_id >= view->low_limit_id) {
        　　　　return(FALSE);
        　　}
3.當行記錄的事務ID在活動范圍之中時，判斷是否在活動鏈表中，如果在就不可見，如果不在就是可見的。
    　　for (i = 0; i < n_ids; i++) {
        　　　　trx_id_t view_trx_id
        　　　　　　= read_view_get_nth_trx_id(view, n_ids - i - 1);
        　　　　if (trx_id <= view_trx_id) {
        　　　　return(trx_id != view_trx_id);
        　　　　}
        　　}

Read view 圖解：

對于上文關于MySQL數(shù)據(jù)庫的事務隔離和MVCC，大家覺得是自己想要的嗎？如果想要了解更多相關，可以繼續(xù)關注我們的行業(yè)資訊板塊。

另外有需要云服務器可以了解下創(chuàng)新互聯(lián)scvps.cn，海內(nèi)外云服務器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務器、裸金屬服務器、高防服務器、香港服務器、美國服務器、虛擬主機、免備案服務器”等云主機租用服務以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應用場景需求。

分享文章：關于MySQL數(shù)據(jù)庫的事務隔離和MVCC的詳細知識-創(chuàng)新互聯(lián)
標題來源：http://www.js-pz168.com/article8/disdop.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供手機網(wǎng)站建設、小程序開發(fā)、自適應網(wǎng)站、品牌網(wǎng)站建設、搜索引擎優(yōu)化、電子商務

廣告

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