## 前言 之前分析一個死鎖問題，發現自己對資料庫隔離級別理解還不夠清楚，所以趁著這幾天假期，整理一下MySQL事務的四大隔離級別相關知識，希望對大家有幫助~  ## 事務 ### 什麼是事務？ 事務，由一個有限的資料庫操作序列構成，這些操作要麼全部執行,要麼全部不執行，是一個不可分割的工作單位。 > 假如A轉賬給B 100 元，先從A的賬戶里扣除 100 元，再在 B 的賬戶上加上 100 元。如果扣完A的100元后，還沒來得及給B加上，銀行系統異常了，最後導致A的餘額減少了，B的餘額卻沒有增加。所以就需要事務，將A的錢回滾回去，就是這麼簡單。 ### 事務的四大特性  - **原子性：** 事務作為一個整體被執行，包含在其中的對資料庫的操作要麼全部都執行，要麼都不執行。 - **一致性：** 指在事務開始之前和事務結束以後，資料不會被破壞，假如A賬戶給B賬戶轉10塊錢，不管成功與否，A和B的總金額是不變的。 - **隔離性：** 多個事務併發訪問時，事務之間是相互隔離的，一個事務不應該被其他事務干擾，多個併發事務之間要相互隔離。。 - **永續性：** 表示事務完成提交後，該事務對資料庫所作的操作更改，將持久地儲存在資料庫之中。 ## 事務併發存在的問題 事務併發執行存在什麼問題呢，換句話說就是，一個事務是怎麼幹擾到其他事務的呢？看例子吧~ 假設現在有表： ``` CREATE TABLE `account` ( `id` int(11) NOT NULL, `name` varchar(255) DEFAULT NULL, `balance` int(11) DEFAULT NULL, PRIMARY KEY (`id`), UNIQUE KEY `un_name_idx` (`name`) USING BTREE ) ENGINE=InnoDB DEFAULT CHARSET=utf8; ``` 表中有資料：  ### 髒讀（dirty read） 假設現在有兩個事務A、B： - 假設現在A的餘額是100，事務A正在準備查詢Jay的餘額 - 這時候，事務B先扣減Jay的餘額，扣了10 - 最後A 讀到的是扣減後的餘額  由上圖可以發現，事務A、B交替執行，事務A被事務B干擾到了，因為事務A讀取到事務B未提交的資料,這就是**髒讀**。 ### 不可重複讀（unrepeatable read） 假設現在有兩個事務A和B： - 事務A先查詢Jay的餘額，查到結果是100 - 這時候事務B 對Jay的賬戶餘額進行扣減，扣去10後，提交事務 - 事務A再去查詢Jay的賬戶餘額發現變成了90  事務A又被事務B干擾到了！在事務A範圍內，兩個相同的查詢，讀取同一條記錄，卻返回了不同的資料，這就是**不可重複讀**。 ### 幻讀 假設現在有兩個事務A、B： - 事務A先查詢id大於2的賬戶記錄，得到記錄id=2和id=3的兩條記錄 - 這時候，事務B開啟，插入一條id=4的記錄，並且提交了 - 事務A再去執行相同的查詢，卻得到了id=2,3,4的3條記錄了。  事務A查詢一個範圍的結果集，另一個併發事務B往這個範圍中插入/刪除了資料，並靜悄悄地提交，然後事務A再次查詢相同的範圍，兩次讀取得到的結果集不一樣了，這就是**幻讀**。 ## 事務的四大隔離級別實踐 既然併發事務存在**髒讀、不可重複、幻讀**等問題，InnoDB實現了哪幾種事務的隔離級別應對呢？ - 讀未提交（Read Uncommitted） - 讀已提交（Read Committed） - 可重複讀（Repeatable Read） - 序列化（Serializable） ### 讀未提交（Read Uncommitted） 想學習一個知識點，最好的方式就是實踐之。好了，我們去資料庫給它設定**讀未提交**隔離級別，實踐一下吧~  先把事務隔離級別設定為read uncommitted，開啟事務A，查詢id=1的資料 ``` set session transaction isolation level read uncommitted; begin; select * from account where id =1; ``` 結果如下：  這時候，另開一個視窗開啟mysql，也把當前事務隔離級別設定為read uncommitted，開啟事務B，執行更新操作 ``` set session transaction isolation level read uncommitted; begin; update account set balance=balance+20 where id =1; ``` 接著回事務A的視窗，再查account表id=1的資料，結果如下：  可以發現，在**讀未提交（Read Uncommitted）** 隔離級別下，一個事務會讀到其他事務未提交的資料的，即存在**髒讀**問題。事務B都還沒commit到資料庫呢，事務A就讀到了，感覺都亂套了。。。實際上，讀未提交是隔離級別最低的一種。 ### 已提交讀（READ COMMITTED） 為了避免髒讀，資料庫有了比**讀未提交**更高的隔離級別，即**已提交讀**。  把當前事務隔離級別設定為已提交讀（READ COMMITTED），開啟事務A，查詢account中id=1的資料 ``` set session transaction isolation level read committed; begin; select * from account where id =1; ``` 另開一個視窗開啟mysql，也把事務隔離級別設定為read committed，開啟事務B，執行以下操作 ``` set session transaction isolation level read committed; begin; update account set balance=balance+20 where id =1; ``` 接著回事務A的視窗，再查account資料，發現數據沒變：  我們再去到事務B的視窗執行commit操作： ``` commit; ``` 最後回到事務A視窗查詢，發現數據變了：  由此可以得出結論，隔離級別設定為**已提交讀（READ COMMITTED）** 時，已經不會出現髒讀問題了，當前事務只能讀取到其他事務提交的資料。但是，你站在事務A的角度想想，存在其他問題嗎？ **提交讀的隔離級別會有什麼問題呢？** 在同一個事務A裡，相同的查詢sql，讀取同一條記錄（id=1），讀到的結果是不一樣的，即**不可重複讀**。所以，隔離級別設定為read committed的時候，還會存在**不可重複讀**的併發問題。 ### 可重複讀（Repeatable Read） 如果你的老闆要求，在同個事務中，查詢結果必須是一致的，即老闆要求你解決不可重複的併發問題，怎麼辦呢？老闆，臣妾辦不到？來實踐一下**可重複讀（Repeatable Read）** 這個隔離級別吧~  哈哈，步驟1、2、6的查詢結果都是一樣的，即**repeatable read解決了不可重複讀問題**，是不是心裡美滋滋的呢，終於解決老闆的難題了~ **RR級別是否解決了幻讀問題呢？** 再來看看網上的一個熱點問題，有關於RR級別下，是否解決了幻讀問題？我們來實踐一下：  由圖可得，步驟2和步驟6查詢結果集沒有變化，看起來RR級別是已經解決幻讀問題了~ 但是呢，**RR級別還是存在這種現象**：  其實，上圖如果事務A中，沒有```update account set balance=200 where id=5;```這步操作，```select * from account where id>2```查詢到的結果集確實是不變，這種情況沒有**幻讀**問題。但是，有了update這個騷操作，同一個事務，相同的sql，查出的結果集不同，這個是符合了**幻讀**的定義~ 這個問題，親愛的朋友，你覺得它算幻讀問題嗎？ ### 序列化（Serializable） 前面三種資料庫隔離級別，都有一定的併發問題，現在放大招吧，實踐SERIALIZABLE隔離級別。 把事務隔離級別設定為Serializable，開啟事務A，查詢account表資料 ``` set session transaction isolation level serializable; select @@tx_isolation; begin; select * from account; ``` 另開一個視窗開啟mysql，也把事務隔離級別設定為Serializable，開啟事務B，執行插入一條資料： ``` set session transaction isolation level serializable; select @@tx_isolation; begin; insert into account(id,name,balance) value(6,'Li',100); ``` 執行結果如下：  由圖可得，當資料庫隔離級別設定為serializable的時候，事務B對錶的寫操作，在等事務A的讀操作。其實，這是隔離級別中最嚴格的，讀寫都不允許併發。它保證了最好的安全性，效能卻是個問題~ ## MySql隔離級別的實現原理 實現隔離機制的方法主要有兩種： - 讀寫鎖 - 一致性快照讀，即 MVCC MySql使用不同的鎖策略(Locking Strategy)/MVCC來實現四種不同的隔離級別。RR、RC的實現原理跟MVCC有關，RU和Serializable跟鎖有關。 ### 讀未提交（Read Uncommitted） **官方說法：** > SELECT statements are performed in a nonlocking fashion, but a possible earlier version of a row might be used. Thus, using this isolation level, such reads are not consistent. 讀未提交，採取的是讀不加鎖原理。 - 事務讀不加鎖，不阻塞其他事務的讀和寫 - 事務寫阻塞其他事務寫，但不阻塞其他事務讀； ### 序列化（Serializable) **官方的說法:** > InnoDB implicitly converts all plain SELECT statements to SELECT ... FOR SHARE if autocommit is disabled. If autocommit is enabled, the SELECT is its own transaction. It therefore is known to be read only and can be serialized if performed as a consistent (nonlocking) read and need not block for other transactions. (To force a plain SELECT to block if other transactions have modified the selected rows, disable autocommit.) - 所有SELECT語句會隱式轉化為```SELECT ... FOR SHARE```，即加共享鎖。 - 讀加共享鎖，寫加排他鎖，讀寫互斥。如果有未提交的事務正在修改某些行，所有select這些行的語句都會阻塞。 ### MVCC的實現原理 MVCC，中文叫**多版本併發控制**，它是通過讀取歷史版本的資料，來降低併發事務衝突，從而提高併發效能的一種機制。它的實現依賴於**隱式欄位、undo日誌、快照讀&當前讀、Read View**，因此，我們先來了解這幾個知識點。 #### 隱式欄位 對於InnoDB儲存引擎，每一行記錄都有兩個隱藏列**DB_TRX_ID、DB_ROLL_PTR**，如果表中沒有主鍵和非NULL唯一鍵時，則還會有第三個隱藏的主鍵列**DB_ROW_ID**。 - DB_TRX_ID，記錄每一行最近一次修改（修改/更新）它的事務ID，大小為6位元組； - DB_ROLL_PTR，這個隱藏列就相當於一個指標，指向回滾段的undo日誌，大小為7位元組； - DB_ROW_ID，單調遞增的行ID，大小為6位元組；  #### undo日誌 > - 事務未提交的時候，修改資料的映象（修改前的舊版本），存到undo日誌裡。以便事務回滾時，恢復舊版本資料，撤銷未提交事務資料對資料庫的影響。 >- undo日誌是邏輯日誌。可以這樣認為，當delete一條記錄時，undo log中會記錄一條對應的insert記錄，當update一條記錄時，它記錄一條對應相反的update記錄。 > - 儲存undo日誌的地方，就是**回滾段**。 多個事務並行操作某一行資料時，不同事務對該行資料的修改會產生多個版本，然後通過回滾指標（DB_ROLL_PTR）連一條**Undo日誌鏈**。 我們通過例子來看一下~ ``` mysql> select * from account ; +----+------+---------+ | id | name | balance | +----+------+---------+ | 1 | Jay | 100 | +----+------+---------+ 1 row in set (0.00 sec) ``` - 假設表accout現在只有一條記錄，插入該該記錄的事務Id為100 - 如果事務B（事務Id為200），對id=1的該行記錄進行更新，把balance值修改為90 事務B修改後，形成的**Undo Log鏈**如下：  #### 快照讀&當前讀 **快照讀：** 讀取的是記錄資料的可見版本（有舊的版本），不加鎖,普通的select語句都是快照讀,如： ``` select * from account where id>2; ``` **當前讀：** 讀取的是記錄資料的最新版本，顯示加鎖的都是當前讀 ``` select * from account where id>2 lock in share mode; select * from account where id>2 for update; ``` #### Read View - Read View就是事務執行**快照讀**時，產生的讀檢視。 - 事務執行快照讀時，會生成資料庫系統當前的一個快照，記錄當前系統中還有哪些活躍的讀寫事務，把它們放到一個列表裡。 - Read View主要是用來做可見性判斷的，即判斷當前事務可見哪個版本的資料~ 為了下面方便討論Read View可見性規則，先定義幾個變數 > - m_ids:當前系統中那些活躍的讀寫事務ID,它資料結構為一個List。 > - min_limit_id:m_ids事務列表中，最小的事務ID > - max_limit_id:m_ids事務列表中，最大的事務ID - 如果DB_TRX_ID < min_limit_id，表明生成該版本的事務在生成ReadView前已經提交(因為事務ID是遞增的)，所以該版本可以被當前事務訪問。 - 如果DB_TRX_ID > m_ids列表中最大的事務id，表明生成該版本的事務在生成ReadView後才生成，所以該版本不可以被當前事務訪問。 - 如果 min_li