數據庫事務的隔離級別有4種，由低到高分別為Read uncommitted 、Read committed 、Repeatable read 、Serializable 。而且，在事務的並發操作中可能會出現臟讀，不可重復讀，幻讀。下面通過事例一一闡述它們的概念與聯系。
臟讀、不可重復讀、幻象讀概念說明：
臟讀：指當一個事務正在訪問數據，並且對數據進行了修改，而這種數據還沒有提交到數據庫中，這時，另外一個事務也訪問這個數據，然后使用了這個數據。因為這個數據還沒有提交那么另外一個事務讀取到的這個數據我們稱之為臟數據。依據臟數據所做的操作肯能是不正確的。
不可重復讀：指在一個事務內，多次讀同一數據。在這個事務還沒有執行結束，另外一個事務也訪問該同一數據，那么在第一個事務中的兩次讀取數據之間，由於第二個事務的修改第一個事務兩次讀到的數據可能是不一樣的，這樣就發生了在一個事物內兩次連續讀到的數據是不一樣的，這種情況被稱為是不可重復讀。
幻象讀：一個事務先后讀取一個范圍的記錄，但兩次讀取的紀錄數不同，我們稱之為幻象讀（兩次執行同一條 select 語句會出現不同的結果，第二次讀會增加一數據行，並沒有說這兩次執行是在同一個事務中）
讀未提交 （Read uncommitted）
讀未提交，顧名思義，就是一個事務可以讀取另一個未提交事務的數據。
事例：老板要給程序員發工資，程序員的工資是3.6萬/月。但是發工資時老板不小心按錯了數字，按成3.9萬/月，該錢已經打到程序員的戶口，但是事務還沒有提交，就在這時，程序員去查看自己這個月的工資，發現比往常多了3千元，以為漲工資了非常高興。但是老板及時發現了不對，馬上回滾差點就提交了的事務，將數字改成3.6萬再提交。
分析：實際程序員這個月的工資還是3.6萬，但是程序員看到的是3.9萬。他看到的是老板還沒提交事務時的數據。這就是臟讀。因此，在這種隔離級別下，查詢是不會加鎖的，也由於查詢的不加鎖，所以這種隔離級別的一致性是最差的，可能會產生“臟讀”、“不可重復讀”、“幻讀”。如無特殊情況，基本是不會使用這種隔離級別的。
那怎么解決臟讀呢？Read committed！讀提交，能解決臟讀問題。
讀提交（Read Committed）
讀提交，顧名思義，就是只能讀到已經提交了的內容
事例：程序員拿着信用卡去享受生活（卡里當然是只有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）什么是幻讀
- 前提條件：InnoDB引擎，可重復讀隔離級別，使用當前讀時。
在一次事務里面，多次查詢之后，結果集的個數不一致的情況叫做幻讀。而多出來或者少的哪一行被叫做 幻行
- 表現：一個事務(同一個read view)在前后兩次查詢同一范圍的時候，后一次查詢看到了前一次查詢沒有看到的行。兩點需要說明：
1、在可重復讀隔離級別下，普通查詢是快照讀，是不會看到別的事務插入的數據的，幻讀只在當前讀下才會出現。
2、幻讀專指新插入的行，讀到原本存在行的更新結果不算。因為當前讀的作用就是能讀到所有已經提交記錄的最新值。
（2）幻讀產生的原因
行鎖只能鎖住行，即使把所有的行記錄都上鎖，也阻止不了新插入的記錄。
（3）如何解決幻讀？
- 在快照讀讀情況下，mysql通過mvcc來避免幻讀。
- 在當前讀讀情況下，mysql通過next-key來避免幻讀
備注：什么是快照讀、當前讀
- 快照讀, 讀取專門的快照 (對於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技術來實現。所以說
總結一下：
- 為什么會出現“臟讀”？因為沒有“select”操作沒有規矩。
- 為什么會出現“不可重復讀”？因為“update”操作沒有規矩。
- 為什么會出現“幻讀”？因為“insert”和“delete”操作沒有規矩。
- “讀未提（Read Uncommitted）”能預防啥？啥都預防不了。
- “讀提交（Read Committed）”能預防啥？使用“快照讀（Snapshot Read）”，避免“臟讀”，但是可能出現“不可重復讀”和“幻讀”。
- “可重復讀（Repeated Red）”能預防啥？使用“快照讀（Snapshot Read）”，鎖住被讀取記錄，避免出現“臟讀”、“不可重復讀”，但是可能出現“幻讀”。
- “串行化（Serializable）”能預防啥？排排坐，吃果果，有效避免“臟讀”、“不可重復讀”、“幻讀”，不過效果誰用誰知道。
出處：https://blog.csdn.net/qq_33290787/article/details/51924963
https://baijiahao.baidu.com/s?id=1611918898724887602&wfr=spider&for=pc