原文地址：https://www.jianshu.com/p/4e3edbedb9a8
===========================================================================================
隔離級別 臟讀（Dirty Read） 不可重復讀（NonRepeatable Read） 幻讀（Phantom Read）
===========================================================================================
未提交讀（Read uncommitted） 可能 可能 可能
已提交讀（Read committed） 不可能 可能 可能
可重復讀（Repeatable read） 不可能 不可能 可能
可串行化（Serializable ） 不可能 不可能 不可能
===========================================================================================
·未提交讀(Read Uncommitted)：允許臟讀，也就是可能讀取到其他會話中未提交事務修改的數據
·提交讀(Read Committed)：只能讀取到已經提交的數據。Oracle等多數數據庫默認都是該級別 (不重復讀)
·可重復讀(Repeated Read)：可重復讀。在同一個事務內的查詢都是事務開始時刻一致的，InnoDB默認級別。在SQL標准中，該隔離級別消除了不可重復讀，但是還存在幻象讀
·串行讀(Serializable)：完全串行化的讀，每次讀都需要獲得表級共享鎖，讀寫相互都會阻塞
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
首先創建一個表account。創建表的過程略過（由於InnoDB存儲引擎支持事務，所以將表的存儲引擎設置為InnoDB）。表的結構如下：
表結構
然后往表中插入兩條數據，插入后結果如下：
數據
為了說明問題，我們打開兩個控制台分別進行登錄來模擬兩個用戶（暫且成為用戶A和用戶B吧），並設置當前MySQL會話的事務隔離級別。
一. read uncommitted（讀取未提交數據）
具體用戶A的操作如下：
-
set
session
transaction
isolation
level
read uncommitted；
-
start
transaction;
-
select *
from
account;
結果如下：
數據
用戶B的操作如下：
-
set
session
transaction
isolation
level
read uncommitted；
-
start
transaction;
-
update
account
set
account=
account+
200
where
id =
1;
隨后我們在A用戶中查詢數據，結果如下：
uncommittedA數據
結論一：
我們將事務隔離級別設置為read uncommitted，即便是事務沒有commit，但是我們仍然能讀到未提交的數據，這是所有隔離級別中最低的一種。
那么這么做有什么問題嗎？
那就是我們在一個事務中可以隨隨便便讀取到其他事務未提交的數據，這還是比較麻煩的，我們叫臟讀。我不知道這個名字是怎么起的，為了增強大家的印象，可以這么想，這個事務好輕浮啊，飢渴到連別人沒提交的東西都等不及，真臟，呸！
實際上我們的數據改變了嗎？
答案是否定的，因為只有事務commit后才會更新到數據庫。
二. read committed（可以讀取其他事務提交的數據）---大多數數據庫默認的隔離級別
同樣的辦法，我們將用戶B所在的會話當前事務隔離級別設置為read commited。
在用戶A所在的會話中我們執行下面操作：
update account set account=account-200 where id=1;
read committed
我們將id=1的用戶account減200。然后查詢，發現id=1的用戶account變為800。
在B用戶所在的會話中查詢：
select * from account；
結果如下：
read committedB
我們會發現數據並沒有變，還是1000。
接着在會話A中我們將事務提交：
commit;
在會話B中查詢結果如下：
read committedB1
結論二：
當我們將當前會話的隔離級別設置為read committed的時候，當前會話只能讀取到其他事務提交的數據，未提交的數據讀不到。
那么這么做有什么問題嗎？
那就是我們在會話B同一個事務中，讀取到兩次不同的結果。這就造成了不可重復讀，就是兩次讀取的結果不同。這種現象叫不可重復讀。
三. repeatable read（可重讀）---MySQL默認的隔離級別
現在有個需求，就是老板說在同一個事務中查詢結果必須保持一致，如果你是數據庫，你會怎么做？數據庫是這么做的。
在會話B中我們當前事務隔離級別為repeatable read。具體操作如下：
-
set
session
transaction
isolation
level repeatable
read;
-
start
transaction;
接着在會話B中查詢數據：
repeatablereadB1
我們在A用戶所在會話中為表account添加一條數據：
-
insert
into
account(
id,
account)
value(
3,
1000);
-
commit;
然后我們查詢看數據插入是否成功：
repeatable readA
回到B用戶所在的會話，我們查詢結果：
repeatablereadB2
用戶B在他所在的會話中想插入一條新數據id=3，value=1000。來我們操作下：
readpeatablereadB3
什么？竟然插不進去，說我數據重復？
用戶B當然不服啊，因為查詢到數據只有兩條啊，為什么插入id=3說我數據重復了呢？
我再看一遍，莫非我眼花了？
repeatablereadB2
試想一下，在實際中用戶A和用戶B肯定是相互隔離的，彼此不知道操作什么。用戶B碰到這種現象，肯定會炸毛的啊，明明不存在的數據，插入卻說主鍵id=3數據重復了。
結論三：
當我們將當前會話的隔離級別設置為repeatable read的時候，當前會話可以重復讀，就是每次讀取的結果集都相同，而不管其他事務有沒有提交。
有什么問題嗎？
管他呢，老板的要求滿足了。要一個事務中讀取的數據一致（可重復讀）。我只能這么做啊，打腫臉裝胖子。數據已經發生改變，但是我還是要保持一致。但是，出現了用戶B面對的問題，這種現象叫幻讀（記得當時就在這個地方糾結好久，到底什么是幻讀啊）。
四. serializable（串行化）
同樣，我們將用戶B所在的會話的事務隔離級別設置為serializable並開啟事務。
-
set
session
transaction
isolation
level
serializable;
-
start
transaction;
在用戶B所在的會話中我們執行下面操作：
select * from account;
結果如下：
serializableA
那我們這個時候在用戶A所在的會話中寫數據呢？
readcommittedA1
我們發現用戶A所在的會話陷入等待，如果超時（這個時間可以進行配置），會出現Lock wait time out提示：
readcommittedA2
如果在等待期間我們用戶B所在的會話事務提交，那么用戶A所在的事務的寫操作將提示操作成功。