來自http://www.jianshu.com/p/4e3edbedb9a8 好久沒碰數據庫了，只是想起自己當時在搞數據庫的時候在事務隔離級別這塊老是卡，似懂非懂的。現在想把這塊整理出來，盡量用最簡潔的語言描述出來，供新人參考。 首先創建一個表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所在的事務的寫操作將提示操作成功。 ### 結論四： ### 當我們將當前會話的隔離級別設置為serializable的時候，其他會話對該表的寫操作將被掛起。可以看到，這是隔離級別中最嚴格的，但是這樣做勢必對性能造成影響。所以在實際的選用上，我們要根據當前具體的情況選用合適的。 作者：傘U 鏈接：http://www.jianshu.com/p/4e3edbedb9a8 來源：簡書 著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。