數據庫事務的隔離級別有4種,由低到高分別爲Read uncommitted 、Read committed 、Repeatable read 、Serializable 。並且,在事務的併發操做中可能會出現髒讀,不可重複讀,幻讀。下面經過事例一一闡述它們的概念與聯繫。mysql
髒讀、不可重複讀、幻象讀概念說明: 程序員
髒讀:指當一個事務正在訪問數據,而且對數據進行了修改,而這種數據尚未提交到數據庫中,這時,另一個事務也訪問這個數據,而後使用了這個數據。由於這個數據尚未提交那麼另一個事務讀取到的這個數據咱們稱之爲髒數據。依據髒數據所作的操做肯能是不正確的。
不可重複讀:指在一個事務內,屢次讀同一數據。在這個事務尚未執行結束,另一個事務也訪問該同一數據,那麼在第一個事務中的兩次讀取數據之間,因爲第二個事務的修改第一個事務兩次讀到的數據多是不同的,這樣就發生了在一個事物內兩次連續讀到的數據是不同的,這種狀況被稱爲是不可重複讀。
幻象讀:一個事務前後讀取一個範圍的記錄,但兩次讀取的紀錄數不一樣,咱們稱之爲幻象讀(兩次執行同一條 select 語句會出現不一樣的結果,第二次讀會增長一數據行,並無說這兩次執行是在同一個事務中)sql
讀未提交 (Read uncommitted)數據庫
讀未提交,顧名思義,就是一個事務能夠讀取另外一個未提交事務的數據。併發
事例:老闆要給程序員發工資,程序員的工資是3.6萬/月。可是發工資時老闆不當心按錯了數字,按成3.9萬/月,該錢已經打到程序員的戶口,可是事務尚未提交,就在這時,程序員去查看本身這個月的工資,發現比往常多了3千元,覺得漲工資了很是高興。可是老闆及時發現了不對,立刻回滾差點就提交了的事務,將數字改爲3.6萬再提交。mvc
分析:實際程序員這個月的工資仍是3.6萬,可是程序員看到的是3.9萬。他看到的是老闆還沒提交事務時的數據。這就是髒讀。所以,在這種隔離級別下,查詢是不會加鎖的,也因爲查詢的不加鎖,因此這種隔離級別的一致性是最差的,可能會產生「髒讀」、「不可重複讀」、「幻讀」。如無特殊狀況,基本是不會使用這種隔離級別的。ide
那怎麼解決髒讀呢?Read committed!讀提交,能解決髒讀問題。高併發
讀提交(Read Committed)性能
讀提交,顧名思義,就是隻能讀到已經提交了的內容spa
事例:程序員拿着信用卡去享受生活(卡里固然是隻有3.6萬),當他埋單時(程序員事務開啓),收費系統事先檢測到他的卡里有3.6萬,就在這個時候!!程序員的妻子要把錢所有轉出充當家用,並提交。當收費系統準備扣款時,再檢測卡里的金額,發現已經沒錢了(第二次檢測金額固然要等待妻子轉出金額事務提交完)。程序員就會很鬱悶,明明卡里是有錢的…
分析:這就是讀提交,如有事務對數據進行更新(UPDATE)操做時,讀操做事務要等待這個更新操做事務提交後才能讀取數據,能夠解決髒讀問題。但在這個事例中,出現了一個事務範圍內兩個相同的查詢卻返回了不一樣數據,這就是不可重複讀。
這是各類系統中最經常使用的一種隔離級別,也是SQL Server和Oracle的默認隔離級別。這種隔離級別可以有效的避免髒讀,但除非在查詢中顯示的加鎖,如:
select * from T where ID=2 lock in share mode; select * from T where ID=2 for update;
否則,普通的查詢是不會加鎖的。
那爲何「讀提交」同「讀未提交」同樣,都沒有查詢加鎖,可是卻可以避免髒讀呢?
這就要說道另外一個機制「快照(snapshot)」,而這種既能保證一致性又不加鎖的讀也被稱爲「快照讀(Snapshot Read)」
假設沒有「快照讀」,那麼當一個更新的事務沒有提交時,另外一個對更新數據進行查詢的事務會由於沒法查詢而被阻塞(由於上了X鎖,即寫鎖,因此不能獲得S鎖,即讀鎖),這種狀況下,併發能力就至關的差。而「快照讀」就能夠完成高併發的查詢,不過,「讀提交」只能避免「髒讀」,並不能避免「不可重複讀」和「幻讀」。
那怎麼解決可能的不可重複讀問題?Repeatable read !
可重複讀(Repeated Read)
可重複讀,顧名思義,就是專門針對「不可重複讀」這種狀況而制定的隔離級別,天然,它就能夠有效的避免「不可重複讀」。而它也是MySql的默認隔離級別。
事例:程序員拿着信用卡去享受生活(卡里固然是隻有3.6萬),當他埋單時(事務開啓,不容許其餘事務的UPDATE修改操做),收費系統事先檢測到他的卡里有3.6萬。這個時候他的妻子不能轉出金額了。接下來收費系統就能夠扣款了。
分析:重複讀能夠解決不可重複讀問題。寫到這裏,應該明白的一點就是,不可重複讀對應的是修改,即UPDATE操做。可是可能還會有幻讀問題。由於幻讀問題對應的是插入INSERT操做,而不是UPDATE操做。
何時會出現幻讀?
事例:程序員某一天去消費,花了2千元,而後他的妻子去查看他今天的消費記錄(全表掃描FTS,妻子事務開啓),看到確實是花了2千元,就在這個時候,程序員花了1萬買了一部電腦,即新增INSERT了一條消費記錄,並提交。當妻子打印程序員的消費記錄清單時(妻子事務提交),發現花了1.2萬元,彷佛出現了幻覺,這就是幻讀。
在這個級別下,普通的查詢一樣是使用的「快照讀」,可是,和「讀提交」不一樣的是,當事務啓動時,就不容許進行「修改操做(Update)」了,而「不可重複讀」偏偏是由於兩次讀取之間進行了數據的修改,所以,「可重複讀」可以有效的避免「不可重複讀」,但卻避免不了「幻讀」,由於幻讀是因爲「插入或者刪除操做(Insert or Delete)」而產生的。
那怎麼解決幻讀問題?Serializable!
序列化 Serializable
這是數據庫最高的隔離級別,這種級別下,事務「串行化順序執行」,也就是一個一個排隊執行。這種級別下,「髒讀」、「不可重複讀」、「幻讀」均可以被避免,可是執行效率奇差,性能開銷也最大,因此基本沒人會用。
值得一提的是:大多數數據庫默認的事務隔離級別是Read committed,好比Sql Server , Oracle。Mysql的默認隔離級別是Repeatable read。
MySql如何解決幻讀問題?
(1)什麼是幻讀
在一次事務裏面,屢次查詢以後,結果集的個數不一致的狀況叫作幻讀。而多出來或者少的哪一行被叫作 幻行
(2)幻讀產生的緣由
行鎖只能鎖住行,即便把全部的行記錄都上鎖,也阻止不了新插入的記錄。
(3)如何解決幻讀?
備註:什麼是快照讀、當前讀
- 快照讀, 讀取專門的快照 (對於RC,快照(ReadView)會在每一個語句中建立。對於RR,快照是在事務啓動時建立的)
```
簡單的select操做便可(不須要加鎖,如: select ... lock in share mode, select ... for update)
```
針對的也是select操做
- 當前讀, 讀取最新版本的記錄, 沒有快照。 在InnoDB中,當前讀取根本不會建立任何快照。
```
select ... lock in share mode
select ... for update
insert
update
delete
針對以下操做, 會讓以下操做阻塞:
```
insert
update
delete
```
- 在RR(可重複讀)級別下, 快照讀是經過MVVC(多版本控制)和undo log來實現的,
當前讀是經過手動加record lock(記錄鎖)和gap lock(間隙鎖)來實現的。因此從上面的顯示來看,若是須要實時顯示數據,仍是須要經過加鎖來實現。這個時候會使用next-key技術來實現。因此說
總結一下:
出處:https://blog.csdn.net/qq_33290787/article/details/51924963
https://baijiahao.baidu.com/s?id=1611918898724887602&wfr=spider&for=pc