再有人問你MySQL的隔離級別是什么，就把這篇文章發給他！
首先要明白什么是事務?
事務是程序中一系列嚴密的操作，所有的操作必須完成，否則在所有的操作中所做的所有的更改都會被撤銷。也就是事務的原子性，一個事務中的一系列的操作要么全部成功，要么就是失敗。
事務的結束有兩種，當事務中所有的步驟全部成功執行的時候，事務提交。如果其中一個步驟失敗，將會發生回滾操作，撤銷到事務開始之前的所有的操作。
事務的ACID
事務具有四個特征
- 原子性 事務是數據庫的邏輯工作單位，事務中包含多個操作，要么都做完，要么都不做
- 隔離性(隔離性也是本文的重點) 事務彼此之間是不能互相干擾的，即一個事務的操作對該數據庫的其他事務操作是隔離的，并發執行的各個事務時間互補干擾
- 持久性 事務一旦提交，其變更是永久性的
- 一致性 事務執行的結果必須滿足從一個狀態變到另一個狀態，因此當數據庫只包含成功事務提交的結果時，就說數據庫處于一致性的狀態。如果數據庫系統在運行時發生系統故障，有些未完成的事務被迫中止，而有一部分修改已經寫入數據庫，這個時候數據庫就處于一種不正確的狀態。
其實以上三個條件(原子性、隔離性、持久性)最終都是為了保持數據庫數據的一致性服務的
MySQL的四種隔離級別
SQL標準定義了四種隔離級別，用來限定事務內外的哪些改變是可見的，哪些是不可見的。
- 讀取未提交的數據【Read Uncommitted】 在該隔離級別，所有的事務都可以看到其他事務沒有提交的執行結果。(實際生產中不可能使用這種隔離級別的)
- 讀取提交的內容【Read Committed】 該隔離級別是大多數數據庫的默認的隔離級別(不是 MySQL 默認的)。它滿足了隔離的簡單定義:一個事務只能看到其他的已經提交的事務所做的改變。這種隔離級別也支持不可重復讀，即同一個 select 可能得到不同的結果
- 可重讀【Repeatable Read】 這是 MySQL 默認的隔離級別，它確保同一個事務在并發讀取數據時，會看到同樣的數據行。不過理論上會導致另外一個問題，【幻讀】?；米x：相同的條件查詢一些數據，然后其他事務【新增】或者是【刪除】了該條件的數據，然后導致讀取的結果不一樣多。InnoDB 存儲引擎通過多版本控制(MVCC)機制解決了該問題
- 可串行化【serializable】 這是事務的最高隔離級別，它通過強制事務排序，使之不可能相互沖突，從而解決了幻讀的問題。它在每個讀的數據行上面加上共享鎖，。但是可能會導致超時和鎖競爭(這種隔離級別太極端，實際生產基本不使用)
這四種隔離級別采用不同的鎖類型來實現
- 臟讀 讀取了前一個事務未提交的或者是回滾的數據
- 不可重復度 同樣的 select 查詢，但是結果不同，過程中有事務更新了原有的數據
- 幻讀 兩次查詢的結果數量不一樣，過程中有事務新增或者是刪除數據
下面對不同的隔離級別產生的不同的問題做一個匯總
各個隔離級別的詳細測試
查看數據庫的隔離級別
- show variables like '%isolation%'
設置數據庫的隔離級別
- set session transaction isolation level Read Uncommitted;
設置數據庫的隔離級別為：Read Uncommitted
實驗一：Read Uncommitted
Read Uncommitted 即：讀取未提交
前置條件：將數據庫的隔離級別設置為read uncomitted;
- set session transaction isolation level Read Uncommitted；
第一步：A開啟事務：start tracsaction;
第二步：A查詢數據：select * from test;
第三步：B開啟事務：start transaction;
第四步：B查詢數據：select * from test;
第五步：B更新數據：update test set num =10 where id = 1;B沒有提交事務
第六步：A讀取數據----A讀取到了B未提交的數據(當前數據庫的隔離級別是：Read Uncommitted)
第七步：B回滾數據：rollback;
第八步：B查詢數據：select * from test;
第九步：A查詢數：select * from test;
結論：事務B更新了數據，但是沒有提交，事務A讀取到的是B未提交的記錄。因為造成臟讀。Read Uncommitted是最低的隔離級別
實驗二：讀取已提交-Read Committed
前置條件：將數據庫的隔離級別設置為：Read Committed;
- set session transaction isolaction level Read Committed;
第一步：A開始事務：start transaction;
第二步：A查詢數據：select *from test;
第三步：B開啟事務：start transaction;
第四步：B查詢數據：select * from test;
第五步：B更新數據：update test set num =10 where id=1
查看結果：
第六步：A查詢數據：select * from test;
第七步：B提交數據：commit;
第八步：A查詢數據：select * from test;
結論：Read Committed 讀已提交的隔離級別解決了臟讀的問題，但是出現了不可重復讀的問題，即事務A在兩次查詢的結果不一致，因為在兩次查詢之間事務B更新了一條數據。
讀已提交的只允許讀取已經提交的記錄 ，但是不要求可重復讀
實驗三：可重讀度-Repeatable Read
前置條件：將數據庫的級別設置為可重復度
set session transaction isolation level repeatable read;
第一步：A開始事務：start transaction;
第二步：A查詢數據：select * from test;
第三步：B開啟事務：start transaction;
第四步：B查詢數據：select * from test;
第五步：B更新數據：update test set num=10 where id=1;
此時B并沒有提交事務
第六步：B查詢數據：select * from test;
第七步：A查詢數據
結果仍然是之前的結果(因為B事務還沒有提交)
第八步：B提交事務：commit;
第九步：A查詢數據：select * from test;此時A查詢的記錄仍然和之前一樣
第十步：B插入一條數據并提交事務：inset into test(num) value(4);
第十一步：A查詢數據，發現結果還是和之前的一樣：select * from test;
第十二步：A提交事務并查詢數據
此時發現A查詢的數據已經和B查詢的結果一致了;
結論：Repeatable Read隔離級別只允許讀取已經提交的事務的記錄，
實驗四：串行化-Serializable
前置條件：將數據庫的隔離級別設置為可串行化
第一步：A開始事務并查詢數據
第二步：B開啟事務并insert數據，發現只能等待，并不能執行下去
第三步：A提交事務
第四步：B插入數據
結論：serializable完全鎖定字段，若一個事務來操作同一份數據，那么就必須等待，直到前一個事務完成并解除鎖為止。是完整的隔離級別，會鎖住對應的數據表，因為會導致效率問題。
本文小結
本片文章并沒有深入的去講解原理，而是讓大家能夠從更直觀的從隔離級別的表面去了解隔離級別，因為我發現我的很多同事對此是模模糊糊，模棱兩可的，但是這個是不可以的，因為技術本身是不允許存在這種歧義的，懂就是懂，才能合理運用，如果模棱兩可，那么在實際運用中一定也是漏洞百出，所以這也是這篇文章誕生的原因。
我們可以先拋開原理與底層的具體實現，先能夠清晰且明了的搞清楚各個專業術語的含義，這未嘗不是一種進步。
