欧美bbbwbbbw肥妇,免费乱码人妻系列日韩,一级黄片

詳解MySQL中事務(wù)隔離級別的實現(xiàn)原理

 更新時間:2021年01月28日 14:59:05   作者:X先生  
這篇文章主要介紹了MySQL中事務(wù)隔離級別的實現(xiàn)原理,幫助大家更好的理解和使用MySQL數(shù)據(jù)庫,感興趣的朋友可以了解下

前言

說到數(shù)據(jù)庫事務(wù),大家腦子里一定很容易蹦出一堆事務(wù)的相關(guān)知識,如事務(wù)的ACID特性,隔離級別,解決的問題(臟讀,不可重復(fù)讀,幻讀)等等,但是可能很少有人真正的清楚事務(wù)的這些特性又是怎么實現(xiàn)的,為什么要有四個隔離級別。

今天我們就先來聊聊MySQL中事務(wù)的隔離性的實現(xiàn)原理,后續(xù)還會繼續(xù)出文章分析其他特性的實現(xiàn)原理。

當然MySQL博大精深,文章疏漏之處在所難免,歡迎批評指正。

說明

MySQL的事務(wù)實現(xiàn)邏輯是位于引擎層的,并且不是所有的引擎都支持事務(wù)的,下面的說明都是以InnoDB引擎為基準。

定義

隔離性(isolation)指的是不同事務(wù)先后提交并執(zhí)行后,最終呈現(xiàn)出來的效果是串行的,也就是說,對于事務(wù)來說,它在執(zhí)行過程中,感知到的數(shù)據(jù)變化應(yīng)該只有自己操作引起的,不存在其他事務(wù)引發(fā)的數(shù)據(jù)變化。

隔離性解決的是并發(fā)事務(wù)出現(xiàn)的問題。

標準SQL隔離級別

隔離性最簡單的實現(xiàn)方式就是各個事務(wù)都串行執(zhí)行了,如果前面的事務(wù)還沒有執(zhí)行完畢,后面的事務(wù)就都等待。但是這樣的實現(xiàn)方式很明顯并發(fā)效率不高,并不適合在實際環(huán)境中使用。

為了解決上述問題,實現(xiàn)不同程度的并發(fā)控制,SQL的標準制定者提出了不同的隔離級別:未提交讀(read uncommitted)、提交讀(read committed)、可重復(fù)讀(repeatable read)、序列化讀(serializable)。其中最高級隔離級別就是序列化讀,而在其他隔離級別中,由于事務(wù)是并發(fā)執(zhí)行的,所以或多或少允許出現(xiàn)一些問題。見以下的矩陣表:

隔離級別(+:允許出現(xiàn),-:不允許出現(xiàn)) 臟讀 不可重復(fù)讀 幻讀
未提交讀                                  +         +               +        
提交讀                                    -         +               +        
可重復(fù)讀                                  -         -               +        
序列化讀                                  -         -               -        

注意,MySQL的InnoDB引擎在提交讀級別通過MVCC解決了不可重復(fù)讀的問題,在可重復(fù)讀級別通過間隙鎖解決了幻讀問題,具體見下面的分析。

實現(xiàn)原理

標準SQL事務(wù)隔離級別實現(xiàn)原理

我們上面遇到的問題其實就是并發(fā)事務(wù)下的控制問題,解決并發(fā)事務(wù)的最常見方式就是悲觀并發(fā)控制了(也就是數(shù)據(jù)庫中的鎖)。標準SQL事務(wù)隔離級別的實現(xiàn)是依賴鎖的,我們來看下具體是怎么實現(xiàn)的:

事務(wù)隔離級別    實現(xiàn)方式                                                     
未提交讀(RU) 事務(wù)對當前被讀取的數(shù)據(jù)不加鎖;

事務(wù)在更新某數(shù)據(jù)的瞬間(就是發(fā)生更新的瞬間),必須先對其加行級共享鎖,直到事務(wù)結(jié)束才釋放。
提交讀(RC)    事務(wù)對當前被讀取的數(shù)據(jù)加行級共享鎖(當讀到時才加鎖),一旦讀完該行,立即釋放該行級共享鎖;

事務(wù)在更新某數(shù)據(jù)的瞬間(就是發(fā)生更新的瞬間),必須先對其加行級排他鎖,直到事務(wù)結(jié)束才釋放。
可重復(fù)讀(RR) 事務(wù)在讀取某數(shù)據(jù)的瞬間(就是開始讀取的瞬間),必須先對其加行級共享鎖,直到事務(wù)結(jié)束才釋放;

事務(wù)在更新某數(shù)據(jù)的瞬間(就是發(fā)生更新的瞬間),必須先對其加行級排他鎖,直到事務(wù)結(jié)束才釋放。
序列化讀(S)   事務(wù)在讀取數(shù)據(jù)時,必須先對其加表級共享鎖 ,直到事務(wù)結(jié)束才釋放;

事務(wù)在更新數(shù)據(jù)時,必須先對其加表級排他鎖 ,直到事務(wù)結(jié)束才釋放。

可以看到,在只使用鎖來實現(xiàn)隔離級別的控制的時候,需要頻繁的加鎖解鎖,而且很容易發(fā)生讀寫的沖突(例如在RC級別下,事務(wù)A更新了數(shù)據(jù)行1,事務(wù)B則在事務(wù)A提交前讀取數(shù)據(jù)行1都要等待事務(wù)A提交并釋放鎖)。

為了不加鎖解決讀寫沖突的問題,MySQL引入了MVCC機制,詳細可見我以前的分析文章:一文讀懂數(shù)據(jù)庫中的樂觀鎖和悲觀鎖和MVCC。

InnoDB事務(wù)隔離級別實現(xiàn)原理

在往下分析之前,我們有幾個概念需要先了解下:

1、鎖定讀和一致性非鎖定讀

鎖定讀:在一個事務(wù)中,主動給讀加鎖,如SELECT ... LOCK IN SHARE MODE 和 SELECT ... FOR UPDATE。分別加上了行共享鎖和行排他鎖。鎖的分類可見我以前的分析文章:你應(yīng)該了解的MySQL鎖分類)。

https://dev.mysql.com/doc/refman/8.0/en/innodb-locking-reads.html

一致性非鎖定讀:InnoDB使用MVCC向事務(wù)的查詢提供某個時間點的數(shù)據(jù)庫快照。查詢會看到在該時間點之前提交的事務(wù)所做的更改,而不會看到稍后或未提交的事務(wù)所做的更改(本事務(wù)除外)。也就是說在開始了事務(wù)之后,事務(wù)看到的數(shù)據(jù)就都是事務(wù)開啟那一刻的數(shù)據(jù)了,其他事務(wù)的后續(xù)修改不會在本次事務(wù)中可見。

Consistent read是InnoDB在RC和RR隔離級別處理SELECT語句的默認模式。一致性非鎖定讀不會對其訪問的表設(shè)置任何鎖,因此,在對表執(zhí)行一致性非鎖定讀的同時,其它事務(wù)可以同時并發(fā)的讀取或者修改它們。

https://dev.mysql.com/doc/refman/8.0/en/innodb-consistent-read.html

2、當前讀和快照讀

當前讀

讀取的是最新版本,像UPDATE、DELETE、INSERT、SELECT ...  LOCK IN SHARE MODE、SELECT ... FOR UPDATE這些操作都是一種當前讀,為什么叫當前讀?就是它讀取的是記錄的最新版本,讀取時還要保證其他并發(fā)事務(wù)不能修改當前記錄,會對讀取的記錄進行加鎖。

快照讀

讀取的是快照版本,也就是歷史版本,像不加鎖的SELECT操作就是快照讀,即不加鎖的非阻塞讀;快照讀的前提是隔離級別不是未提交讀和序列化讀級別,因為未提交讀總是讀取最新的數(shù)據(jù)行,而不是符合當前事務(wù)版本的數(shù)據(jù)行,而序列化讀則會對表加鎖。

3、隱式鎖定和顯式鎖定

隱式鎖定

InnoDB在事務(wù)執(zhí)行過程中,使用兩階段鎖協(xié)議(不主動進行顯示鎖定的情況):

  • 隨時都可以執(zhí)行鎖定,InnoDB會根據(jù)隔離級別在需要的時候自動加鎖;
  • 鎖只有在執(zhí)行commit或者rollback的時候才會釋放,并且所有的鎖都是在同一時刻被釋放。

顯式鎖定

  • InnoDB也支持通過特定的語句進行顯示鎖定(存儲引擎層)
select ... lock in share mode //共享鎖
select ... for update //排他鎖
  • MySQL Server層的顯示鎖定:
lock table
unlock table

了解完上面的概念后,我們來看下InnoDB的事務(wù)具體是怎么實現(xiàn)的(下面的讀都指的是非主動加鎖的select)

事務(wù)隔離級別    實現(xiàn)方式                                                     
未提交讀(RU) 事務(wù)對當前被讀取的數(shù)據(jù)不加鎖,都是當前讀;

事務(wù)在更新某數(shù)據(jù)的瞬間(就是發(fā)生更新的瞬間),必須先對其加行級共享鎖,直到事務(wù)結(jié)束才釋放。
提交讀(RC)    事務(wù)對當前被讀取的數(shù)據(jù)不加鎖,且是快照讀;

事務(wù)在更新某數(shù)據(jù)的瞬間(就是發(fā)生更新的瞬間),必須先對其加行級排他鎖(Record),直到事務(wù)結(jié)束才釋放。

通過快照,在這個級別MySQL就解決了不可重復(fù)讀的問題
可重復(fù)讀(RR) 事務(wù)對當前被讀取的數(shù)據(jù)不加鎖,且是快照讀;

事務(wù)在更新某數(shù)據(jù)的瞬間(就是發(fā)生更新的瞬間),必須先對其加行級排他鎖(Record,GAP,Next-Key),直到事務(wù)結(jié)束才釋放。

通過間隙鎖,在這個級別MySQL就解決了幻讀的問題
序列化讀(S)   事務(wù)在讀取數(shù)據(jù)時,必須先對其加表級共享鎖 ,直到事務(wù)結(jié)束才釋放,都是當前讀;

事務(wù)在更新數(shù)據(jù)時,必須先對其加表級排他鎖 ,直到事務(wù)結(jié)束才釋放。

可以看到,InnoDB通過MVCC很好的解決了讀寫沖突的問題,而且提前一個級別就解決了標準級別下會出現(xiàn)的幻讀和不可重復(fù)讀問題,大大提升了數(shù)據(jù)庫的并發(fā)能力。

一些常見誤區(qū)

幻讀到底包不包括了delete的情況?

不可重復(fù)讀:前后多次讀取一行,數(shù)據(jù)內(nèi)容不一致,針對其他事務(wù)的update和delete操作。為了解決這個問題,使用行共享鎖,鎖定到事務(wù)結(jié)束(也就是RR級別,當然MySQL使用MVCC在RC級別就解決了這個問題)

幻讀:當同一個查詢在不同時間生成不同的行集合時就是出現(xiàn)了幻讀,針對的是其他事務(wù)的insert操作,為了解決這個問題,鎖定整個表到事務(wù)結(jié)束(也就是S級別,當然MySQL使用間隙鎖在RR級別就解決了這個問題)

網(wǎng)上很多文章提到幻讀和提交讀的時候,有的說幻讀包括了delete的情況,有的說delete應(yīng)該屬于提交讀的問題,那到底真相如何呢?我們實際來看下MySQL的官方文檔(如下)

The so-called phantom problem occurs within a transaction when the same query produces different sets of rows at different times. For example, if a SELECT) is executed twice, but returns a row the second time that was not returned the first time, the row is a “phantom” row.
https://dev.mysql.com/doc/refman/5.7/en/innodb-next-key-locking.html

可以看到,幻讀針對的是結(jié)果集前后發(fā)生變化,所以看起來delete的情況應(yīng)該歸為幻讀,但是我們實際分析下上面列出的標準SQL在RR級別的實現(xiàn)原理就知道,標準SQL的RR級別是會對查到的數(shù)據(jù)行加行共享鎖,所以這時候其他事務(wù)想刪除這些數(shù)據(jù)行其實是做不到的,所以在RR下,不會出現(xiàn)因delete而出現(xiàn)幻讀現(xiàn)象,也就是幻讀不包含delete的情況。

MVCC能解決了幻讀問題?

網(wǎng)上很多文章會說MVCC或者MVCC+間隙鎖解決了幻讀問題,實際上MVCC并不能解決幻讀問題。如以下的例子:

begin;

#假設(shè)users表為空,下面查出來的數(shù)據(jù)為空

select * from users; #沒有加鎖

#此時另一個事務(wù)提交了,且插入了一條id=1的數(shù)據(jù)

select * from users; #讀快照,查出來的數(shù)據(jù)為空

update users set name='mysql' where id=1;#update是當前讀,所以更新成功,并生成一個更新的快照

select * from users; #讀快照,查出來id為1的一條記錄,因為MVCC可以查到當前事務(wù)生成的快照

commit;

可以看到前后查出來的數(shù)據(jù)行不一致,發(fā)生了幻讀。所以說只有MVCC是不能解決幻讀問題的,解決幻讀問題靠的是間隙鎖。如下:

begin;

#假設(shè)users表為空,下面查出來的數(shù)據(jù)為空

select * from users lock in share mode; #加上共享鎖

#此時另一個事務(wù)B想提交且插入了一條id=1的數(shù)據(jù),由于有間隙鎖,所以要等待

select * from users; #讀快照,查出來的數(shù)據(jù)為空

update users set name='mysql' where id=1;#update是當前讀,由于不存在數(shù)據(jù),不進行更新

select * from users; #讀快照,查出來的數(shù)據(jù)為空

commit;

#事務(wù)B提交成功并插入數(shù)據(jù)

注意,RR級別下想解決幻讀問題,需要我們顯式加鎖,不然查詢的時候還是不會加鎖的

以上就是詳解MySQL中事務(wù)隔離級別的實現(xiàn)原理的詳細內(nèi)容,更多關(guān)于MySQL 事務(wù)隔離級別的資料請關(guān)注腳本之家其它相關(guān)文章!

相關(guān)文章

  • MySQL中隱式轉(zhuǎn)換的踩坑記錄以及解決方法分享

    MySQL中隱式轉(zhuǎn)換的踩坑記錄以及解決方法分享

    這篇文章主要和大家分享一個MySQL隱式轉(zhuǎn)換時踩過的坑,差點把服務(wù)器整崩潰了,以及最后的解決辦法。文中的示例代碼講解詳細,感興趣的可以了解一下
    2022-11-11
  • Mac上安裝MySQL過程分享

    Mac上安裝MySQL過程分享

    這篇文章主要介紹了Mac上安裝MySQL過程分享,本文共分4步完成,簡單易懂,需要的朋友可以參考下
    2014-11-11
  • mysql版本5.5.x升級到5.6.x步驟分享

    mysql版本5.5.x升級到5.6.x步驟分享

    在我做的一個項目中,最近我對生產(chǎn)服務(wù)器上的一系列系統(tǒng)軟件進行了升級,包括git、nginx、MySQL和PHP。這篇文章講的是升級MySQL的過程,其他軟件的升級將在其他文章中介紹。
    2016-01-01
  • MySQL中的布爾值,怎么存儲false或true

    MySQL中的布爾值,怎么存儲false或true

    這篇文章主要介紹了MySQL中的布爾值,怎么存儲false或true的操作,具有很好的參考價值,希望對大家有所幫助。如有錯誤或未考慮完全的地方,望不吝賜教
    2021-06-06
  • Mysql my.cnf配置文件參數(shù)詳解

    Mysql my.cnf配置文件參數(shù)詳解

    Linux 操作系統(tǒng)中 MySQL 的配置文件是 my.cnf,一般會放在 /etc/my.cnf 或 /etc/mysql/my.cnf 目錄下,這篇文章主要介紹了Mysql my.cnf配置文件參數(shù)詳解,需要的朋友可以參考下
    2023-11-11
  • MySQL交換分區(qū)的實例詳解

    MySQL交換分區(qū)的實例詳解

    這篇文章主要介紹了MySQL交換分區(qū)的實例詳解的相關(guān)資料,需要的朋友可以參考下
    2017-07-07
  • MySQL中l(wèi)imit對查詢語句性能的影響

    MySQL中l(wèi)imit對查詢語句性能的影響

    我們知道,當limit offset rows中的offset很大時,會出現(xiàn)效率問題,那么如果提高limit的執(zhí)行效率呢
    2021-09-09
  • MYSQL悲觀鎖及樂觀鎖方式

    MYSQL悲觀鎖及樂觀鎖方式

    MySQL支持悲觀鎖和樂觀鎖兩種機制,悲觀鎖在執(zhí)行讀寫操作之前先獲取鎖,適用于高并發(fā)場景,但可能引發(fā)性能瓶頸和死鎖問題,樂觀鎖則通過版本號或時間戳等機制判斷數(shù)據(jù)是否被修改,適用于并發(fā)沖突較少的場景
    2024-12-12
  • mysql 增加修改字段類型及刪除字段類型

    mysql 增加修改字段類型及刪除字段類型

    本節(jié)主要介紹了mysql如何增加修改字段類型及刪除字段類型,需要的朋友可以參考下
    2014-07-07
  • Mysql 用戶權(quán)限管理實現(xiàn)

    Mysql 用戶權(quán)限管理實現(xiàn)

    MySQL 是一個多用戶數(shù)據(jù)庫,具有功能強大的訪問控制系統(tǒng),可以為不同用戶指定不同權(quán)限。本文就來介紹一下Mysql 用戶權(quán)限管理實現(xiàn),感興趣的可以了解一下
    2021-05-05

最新評論