4種事務隔離級別

哪四種？

數據庫事務的隔離級別有4種，由低到高分別爲：

• Read uncommitted 讀未提交
• Read committed 讀提交
• Repeatable read 重複讀（從事務操做的角度闡述表示這個事務須要屢次讀取）
• Serializable 序列化，串行化順序執行，至關於鎖表

分別會出現什麼問題?

Read uncommitted

讀未提交，顧名思義，就是一個事務能夠讀取另外一個未提交事務的數據。

事例：老闆要給程序員發工資，程序員的工資是3.6萬/月。可是發工資時老闆不當心按錯了數字，按成3.9萬/月，該錢已經打到程序員的戶口，可是事務尚未提交，就在這時，程序員去查看本身這個月的工資，發現比往常多了3千元，覺得漲工資了很是高興。可是老闆及時發現了不對，立刻回滾差點就提交了的事務，將數字改爲3.6萬再提交。

分析：實際程序員這個月的工資仍是3.6萬，可是程序員看到的是3.9萬。他看到的是老闆還沒提交事務時的數據。這就是==髒讀==。

那怎麼解決髒讀呢？Read committed！讀提交，能解決髒讀問題。

---

Read committed

讀提交，顧名思義，就是一個事務要等另外一個事務提交後才能讀取數據。

事例：程序員拿着信用卡去享受生活（卡里固然是隻有3.6萬），當他埋單時（程序員事務開啓），收費系統事先檢測到他的卡里有3.6萬，就在這個時候！！程序員的妻子要把錢所有轉出充當家用，並提交。當收費系統準備扣款時，再檢測卡里的金額，發現已經沒錢了（==第二次檢測金額固然要等待妻子轉出金額事務提交完==）。程序員就會很鬱悶，明明卡里是有錢的…

分析：這就是讀提交，如有事務對數據進行更新（UPDATE）操做時，讀操做事務要等待這個更新操做事務提交後才能讀取數據，能夠解決髒讀問題。但在這個事例中，出現了==一個事務範圍內兩個相同的查詢卻返回了不一樣數據，這就是==不可重複讀==

那怎麼解決可能的不可重複讀問題？Repeatable read ！

---

Repeatable read

重複讀，就是在開始讀取數據（事務開啓）時，再也不容許修改操做

事例：程序員拿着信用卡去享受生活（卡里固然是隻有3.6萬），當他埋單時（==事務開啓，不容許其餘事務的UPDATE修改操做==），收費系統事先檢測到他的卡里有3.6萬。這個時候他的妻子不能轉出金額了。接下來收費系統就能夠扣款了。

分析：重複讀能夠解決不可重複讀問題。寫到這裏，應該明白的一點就是，==不可重複讀對應的是修改，即UPDATE操做==。可是可能還會有==幻讀==問題。由於==幻讀問題對應的是插入INSERT操做，而不是UPDATE操做。==

何時會出現幻讀？
事例：程序員某一天去消費，花了2千元，而後他的妻子去查看他今天的消費記錄（全表掃描FTS，妻子事務開啓），看到確實是花了2千元，就在這個時候，程序員花了1萬買了一部電腦，即==新增INSERT==了一條消費記錄，並提交。當妻子打印程序員的消費記錄清單時（妻子事務提交），發現花了1.2萬元，彷佛出現了幻覺，這就是==幻讀==。

那怎麼解決幻讀問題？Serializable！

---

Serializable 序列化

Serializable
是最高的事務隔離級別，在該級別下，事務==串行化順序執行==，能夠避免髒讀、不可重複讀與幻讀。可是這種事務隔離級別效率低下，比較耗數據庫性能，通常不使用。

==值得一提的是：大多數數據庫默認的事務隔離級別是Read committed，好比Sql Server , Oracle。Mysql的默認隔離級別是Repeatable read。==

轉自：理解事務的4種隔離級別