本文所說的 MySQL 事務都是指在 InnoDB 引擎下，MyISAM 引擎是不支持事務的。
數據庫事務指的是一組數據操作，事務內的操作要么就是全部成功，要么就是全部失敗，什么都不做，其實不是沒做，是可能做了一部分但是只要有一步失敗，就要回滾所有操作，有點一不做二不休的意思。
假設一個網購付款的操作，用戶付款后要涉及到訂單狀態更新、扣庫存以及其他一系列動作，這就是一個事務，如果一切正常那就相安無事，一旦中間有某個環節異常，那整個事務就要回滾，總不能更新了訂單狀態但是不扣庫存吧，這問題就大了。
事務具有原子性（Atomicity）、一致性（Consistency）、隔離性（Isolation）、持久性（Durability）四個特性，簡稱 ACID，缺一不可。今天要說的就是隔離性。
概念說明
以下幾個概念是事務隔離級別要實際解決的問題，所以需要搞清楚都是什么意思。
臟讀
臟讀指的是讀到了其他事務未提交的數據，未提交意味着這些數據可能會回滾，也就是可能最終不會存到數據庫中，也就是不存在的數據。讀到了並一定最終存在的數據，這就是臟讀。
可重復讀
可重復讀指的是在一個事務內，最開始讀到的數據和事務結束前的任意時刻讀到的同一批數據都是一致的。通常針對數據更新（UPDATE）操作。
不可重復讀
對比可重復讀，不可重復讀指的是在同一事務內，不同的時刻讀到的同一批數據可能是不一樣的，可能會受到其他事務的影響，比如其他事務改了這批數據並提交了。通常針對數據更新（UPDATE）操作。
幻讀
幻讀是針對數據插入（INSERT）操作來說的。假設事務A對某些行的內容作了更改，但是還未提交，此時事務B插入了與事務A更改前的記錄相同的記錄行，並且在事務A提交之前先提交了，而這時，在事務A中查詢，會發現好像剛剛的更改對於某些數據未起作用，但其實是事務B剛插入進來的，讓用戶感覺很魔幻，感覺出現了幻覺，這就叫幻讀。
事務隔離級別
SQL 標准定義了四種隔離級別，MySQL 全都支持。這四種隔離級別分別是：
- 讀未提交（READ UNCOMMITTED）
- 讀提交 （READ COMMITTED）
- 可重復讀 （REPEATABLE READ）
- 串行化 （SERIALIZABLE）
從上往下，隔離強度逐漸增強，性能逐漸變差。采用哪種隔離級別要根據系統需求權衡決定，其中，可重復讀是 MySQL 的默認級別。
事務隔離其實就是為了解決上面提到的臟讀、不可重復讀、幻讀這幾個問題，下面展示了 4 種隔離級別對這三個問題的解決程度。
只有串行化的隔離級別解決了全部這 3 個問題，其他的 3 個隔離級別都有缺陷。
如何設置隔離級別
我們可以通過以下語句查看當前數據庫的隔離級別，通過下面語句可以看出我使用的 MySQL 的隔離級別是 REPEATABLE-READ，也就是可重復讀，這也是 MySQL 的默認級別。
面試官：“講講mysql有幾個事務隔離級別？” 你：“讀未提交，讀已提交，可重復讀，串行化四個！默認是可重復讀” 面試官：“為什么mysql選可重復讀作為默認的隔離級別？” (你面露苦色，不知如何回答！) 面試官:"你們項目中選了哪個隔離級別？為什么？" 你：“當然是默認的可重復讀，至於原因。。呃。。。”
在Oracle，SqlServer中都是選擇讀已提交(Read Commited)作為默認的隔離級別，為什么Mysql不選擇讀已提交(Read Commited)作為默認隔離級別，而選擇可重復讀(Repeatable Read)作為默認的隔離級別呢？
這個是有歷史原因的，當然要從我們的主從復制開始講起了！
主從復制，是基於什么復制的？
是基於binlog復制的！這里不想去搬binlog的概念了，就簡單理解為binlog是一個記錄數據庫更改的文件吧～
binlog有幾種格式？
OK，三種，分別是
- statement:記錄的是修改SQL語句
- row：記錄的是每行實際數據的變更
- mixed：statement和row模式的混合
那Mysql在5.0這個版本以前，binlog只支持STATEMENT這種格式！而這種格式在讀已提交(Read Commited)這個隔離級別下主從復制是有bug的，因此Mysql將可重復讀(Repeatable Read)作為默認的隔離級別！
接下來，就要說說當binlog為STATEMENT格式，且隔離級別為讀已提交(Read Commited)時，有什么bug呢？如下圖所示，在主(master)上執行如下事務
此時在主(master)上執行下列語句
select * from test；輸出如下
+---+ | b | +---+ | 3 | +---+ 1 row in set但是，你在此時在從(slave)上執行該語句，得出輸出如下
Empty set這樣，你就出現了主從不一致性的問題！原因其實很簡單，就是在master上執行的順序為先刪后插！而此時binlog為STATEMENT格式，它記錄的順序為先插后刪！從(slave)同步的是binglog，因此從機執行的順序和主機不一致！就會出現主從不一致！
如何解決？
解決方案有兩種！
(1)隔離級別設為可重復讀(Repeatable Read),在該隔離級別下引入間隙鎖。當Session 1執行delete語句時，會鎖住間隙。那么，Ssession 2執行插入語句就會阻塞住！
(2)將binglog的格式修改為row格式，此時是基於行的復制，自然就不會出現sql執行順序不一樣的問題！奈何這個格式在mysql5.1版本開始才引入。因此由於歷史原因，mysql將默認的隔離級別設為可重復讀(Repeatable Read)，保證主從復制不出問題！
讀未提交
MySQL 事務隔離其實是依靠鎖來實現的，加鎖自然會帶來性能的損失。而讀未提交隔離級別是不加鎖的，所以它的性能是最好的，沒有加鎖、解鎖帶來的性能開銷。但有利就有弊，這基本上就相當於裸奔啊，所以它連臟讀的問題都沒辦法解決。
任何事務對數據的修改都會第一時間暴露給其他事務，即使事務還沒有提交。
下面來做個簡單實驗驗證一下，首先設置全局隔離級別為讀未提交。
set global transaction isolation level read uncommitted;設置完成后，只對之后新起的 session 才起作用，對已經啟動 session 無效。如果用 shell 客戶端那就要重新連接 MySQL，如果用 Navicat 那就要創建新的查詢窗口。
啟動兩個事務，分別為事務A和事務B，在事務A中使用 update 語句，修改 age 的值為10，初始是1 ，在執行完 update 語句之后，在事務B中查詢 user 表，會看到 age 的值已經是 10 了，這時候事務A還沒有提交，而此時事務B有可能拿着已經修改過的 age=10 去進行其他操作了。在事務B進行操作的過程中，很有可能事務A由於某些原因，進行了事務回滾操作，那其實事務B得到的就是臟數據了，拿着臟數據去進行其他的計算，那結果肯定也是有問題的。
順着時間軸往表示兩事務中操作的執行順序，重點看圖中 age 字段的值。讀未提交，其實就是可以讀到其他事務未提交的數據，但沒有辦法保證你讀到的數據最終一定是提交后的數據，如果中間發生回滾，那就會出現臟數據問題，讀未提交沒辦法解決臟數據問題。更別提可重復讀和幻讀了，想都不要想。
讀提交
既然讀未提交沒辦法解決臟數據問題，那么就有了讀提交。讀提交就是一個事務只能讀到其他事務已經提交過的數據，也就是其他事務調用 commit 命令之后的數據。那臟數據問題迎刃而解了。
讀提交事務隔離級別是大多數流行數據庫的默認事務隔離界別，比如 Oracle，但是不是 MySQL 的默認隔離界別。
我們繼續來做一下驗證，首先把事務隔離級別改為讀提交級別。
set global transaction isolation level read committed;之后需要重新打開新的 session 窗口，也就是新的 shell 窗口才可以。
同樣開啟事務A和事務B兩個事務，在事務A中使用 update 語句將 id=1 的記錄行 age 字段改為 10。此時，在事務B中使用 select 語句進行查詢，我們發現在事務A提交之前，事務B中查詢到的記錄 age 一直是1，直到事務A提交，此時在事務B中 select 查詢，發現 age 的值已經是 10 了。
這就出現了一個問題，在同一事務中(本例中的事務B)，事務的不同時刻同樣的查詢條件，查詢出來的記錄內容是不一樣的，事務A的提交影響了事務B的查詢結果，這就是不可重復讀，也就是讀提交隔離每個 select 語句都有自己的一份快照，而不是一個事務一份，所以在不同的時刻，查詢出來的數據可能是不一致的。
讀提交解決了臟讀的問題，但是無法做到可重復讀，也沒辦法解決幻讀。
可重復讀
可重復是對比不可重復而言的，上面說不可重復讀是指同一事物不同時刻讀到的數據值可能不一致。而可重復讀是指，事務不會讀到其他事務對已有數據的修改，及時其他事務已提交，也就是說，事務開始時讀到的已有數據是什么，在事務提交前的任意時刻，這些數據的值都是一樣的。但是，對於其他事務新插入的數據是可以讀到的，這也就引發了幻讀問題。
同樣的，需改全局隔離級別為可重復讀級別。
set global transaction isolation level repeatable read;在這個隔離級別下，啟動兩個事務，兩個事務同時開啟。
首先看一下可重復讀的效果，事務A啟動后修改了數據，並且在事務B之前提交，事務B在事務開始和事務A提交之后兩個時間節點都讀取的數據相同，已經可以看出可重復讀的效
可重復讀做到了，這只是針對已有行的更改操作有效，但是對於新插入的行記錄，就沒這么幸運了，幻讀就這么產生了。我們看一下這個過程：
事務A開始后，執行 update 操作，將 age = 1 的記錄的 name 改為“風箏2號”；
事務B開始后，在事務執行完 update 后，執行 insert 操作，插入記錄 age =1，name = 古時的風箏，這和事務A修改的那條記錄值相同，然后提交。
事務B提交后，事務A中執行 select，查詢 age=1 的數據，這時，會發現多了一行，並且發現還有一條 name = 古時的風箏，age = 1 的記錄，這其實就是事務B剛剛插入的，這就是幻讀。
要說明的是，當你在 MySQL 中測試幻讀的時候，並不會出現上圖的結果，幻讀並沒有發生，MySQL 的可重復讀隔離級別其實解決了幻讀問題，這會在后面的內容說明
串行化
串行化是4種事務隔離級別中隔離效果最好的，解決了臟讀、可重復讀、幻讀的問題，但是效果最差，它將事務的執行變為順序執行，與其他三個隔離級別相比，它就相當於單線程，后一個事務的執行必須等待前一個事務結束。
MySQL 中是如何實現事務隔離的
首先說讀未提交，它是性能最好，也可以說它是最野蠻的方式，因為它壓根兒就不加鎖，所以根本談不上什么隔離效果，可以理解為沒有隔離。
再來說串行化。讀的時候加共享鎖，也就是其他事務可以並發讀，但是不能寫。寫的時候加排它鎖，其他事務不能並發寫也不能並發讀。
最后說讀提交和可重復讀。這兩種隔離級別是比較復雜的，既要允許一定的並發，又想要兼顧的解決問題。
實現可重復讀
為了解決不可重復讀，或者為了實現可重復讀，MySQL 采用了 MVVC (多版本並發控制) 的方式。
我們在數據庫表中看到的一行記錄可能實際上有多個版本，每個版本的記錄除了有數據本身外，還要有一個表示版本的字段，記為 row trx_id，而這個字段就是使其產生的事務的 id，事務 ID 記為 transaction id，它在事務開始的時候向事務系統申請，按時間先后順序遞增。
按照上面這張圖理解，一行記錄現在有 3 個版本，每一個版本都記錄這使其產生的事務 ID，比如事務A的transaction id 是100，那么版本1的row trx_id 就是 100，同理版本2和版本3。
在上面介紹讀提交和可重復讀的時候都提到了一個詞，叫做快照，學名叫做一致性視圖，這也是可重復讀和不可重復讀的關鍵，可重復讀是在事務開始的時候生成一個當前事務全局性的快照，而讀提交則是每次執行語句的時候都重新生成一次快照。
對於一個快照來說，它能夠讀到那些版本數據，要遵循以下規則：
- 當前事務內的更新，可以讀到；
- 版本未提交，不能讀到；
- 版本已提交，但是卻在快照創建后提交的，不能讀到；
- 版本已提交，且是在快照創建前提交的，可以讀到；
利用上面的規則，再返回去套用到讀提交和可重復讀的那兩張圖上就很清晰了。還是要強調，兩者主要的區別就是在快照的創建上，可重復讀僅在事務開始是創建一次，而讀提交每次執行語句的時候都要重新創建一次。
並發寫問題
存在這的情況，兩個事務，對同一條數據做修改。最后結果應該是哪個事務的結果呢，肯定要是時間靠后的那個對不對。並且更新之前要先讀數據，這里所說的讀和上面說到的讀不一樣，更新之前的讀叫做“當前讀”，總是當前版本的數據，也就是多版本中最新一次提交的那版。
假設事務A執行 update 操作， update 的時候要對所修改的行加行鎖，這個行鎖會在提交之后才釋放。而在事務A提交之前，事務B也想 update 這行數據，於是申請行鎖，但是由於已經被事務A占有，事務B是申請不到的，此時，事務B就會一直處於等待狀態，直到事務A提交，事務B才能繼續執行，如果事務A的時間太長，那么事務B很有可能出現超時異常。如下圖所示。
加鎖的過程要分有索引和無索引兩種情況，比如下面這條語句
update user set age=11 where id = 1id 是這張表的主鍵，是有索引的情況，那么 MySQL 直接就在索引數中找到了這行數據，然后干凈利落的加上行鎖就可以了。
而下面這條語句
update user set age=11 where age=10表中並沒有為 age 字段設置索引，所以， MySQL 無法直接定位到這行數據。那怎么辦呢，當然也不是加表鎖了。MySQL 會為這張表中所有行加行鎖，沒錯，是所有行。但是呢，在加上行鎖后，MySQL 會進行一遍過濾，發現不滿足的行就釋放鎖，最終只留下符合條件的行。雖然最終只為符合條件的行加了鎖，但是這一鎖一釋放的過程對性能也是影響極大的。所以，如果是大表的話，建議合理設計索引，如果真的出現這種情況，那很難保證並發度。
解決幻讀
上面介紹可重復讀的時候，那張圖里標示着出現幻讀的地方實際上在 MySQL 中並不會出現，MySQL 已經在可重復讀隔離級別下解決了幻讀的問題。
前面剛說了並發寫問題的解決方式就是行鎖，而解決幻讀用的也是鎖，叫做間隙鎖，MySQL 把行鎖和間隙鎖合並在一起，解決了並發寫和幻讀的問題，這個鎖叫做 Next-Key鎖。
假設現在表中有兩條記錄，並且 age 字段已經添加了索引，兩條記錄 age 的值分別為 10 和 30。
此時，在數據庫中會為索引維護一套B+樹，用來快速定位行記錄。B+索引樹是有序的，所以會把這張表的索引分割成幾個區間。
如圖所示，分成了3 個區間，(負無窮,10]、(10,30]、(30,正無窮]，在這3個區間是可以加間隙鎖的。
之后，我用下面的兩個事務演示一下加鎖過程。
在事務A提交之前，事務B的插入操作只能等待，這就是間隙鎖起得作用。當事務A執行update user set name='風箏2號’ where age = 10; 的時候，由於條件 where age = 10 ，數據庫不僅在 age =10 的行上添加了行鎖，而且在這條記錄的兩邊，也就是(負無窮,10]、(10,30]這兩個區間加了間隙鎖，從而導致事務B插入操作無法完成，只能等待事務A提交。不僅插入 age = 10 的記錄需要等待事務A提交，age<10、10<age<30 的記錄頁無法完成，而大於等於30的記錄則不受影響，這足以解決幻讀問題了。
這是有索引的情況，如果 age 不是索引列，那么數據庫會為整個表加上間隙鎖。所以，如果是沒有索引的話，不管 age 是否大於等於30，都要等待事務A提交才可以成功插入。
總結
MySQL 的 InnoDB 引擎才支持事務，其中可重復讀是默認的隔離級別。
讀未提交和串行化基本上是不需要考慮的隔離級別，前者不加鎖限制，后者相當於單線程執行，效率太差。
讀提交解決了臟讀問題，行鎖解決了並發更新的問題。並且 MySQL 在可重復讀級別解決了幻讀問題，是通過行鎖和間隙鎖的組合 Next-Key 鎖實現的。