MySQL的事務隔離級別和長事務，看這一篇就夠了

提到事務，你們都不陌生，在使用數據庫的時候，咱們總會提到事務，最經典的例子就是轉賬，好比小王的銀行卡上有一百塊，要把這一百塊轉帳，轉帳過程當中的一系列操做，好比查詢餘額、扣減資金、增長資金、更新餘額等，這些操做必須保證是一體的，否則等查詢餘額以後，在扣除資金以前，徹底能夠藉着這個時間再查一次，而後將這個錢轉給另一我的，這樣不就亂套了。

事務的概念各位都不陌生，簡單來講，事務就是要保證一組數據庫操做，要麼所有成功，要麼所有失敗。MySQL數據庫的事務支持是在引擎層實現的。MySQL是一個支持多引擎的系統，可是不是全部的引擎都支持事務，只有InnoDB支持事務。

隔離性與隔離級別

你們都都知道事務的四種屬性ACID，今天咱們就說說其中的 I，也就是隔離性。

數據庫多個事務同時執行的時候，就會出現髒讀（dirty read）、幻讀（phantom read）、不可重複讀 (non-repeatable read)等問題，爲了解決這些問題，就有了隔離級別的概念。

事務的隔離等級越高，效率就會越低，不少時候咱們就在數據準確和效率之間找平衡點。SQL標準的事務隔離級別包括：讀未提交（read uncommitted）、讀提交（read committed）、可重複讀（repeatable read）和串行化（serializable）。可能不少人已經對這幾個概念很熟悉，這裏就簡單介紹一下：

• 讀未提交：一個事務還沒提交時，它作的變動就能被其餘事務看到。

• 讀提交：一個事務只有在提交以後，其它事務才能看到它作的變動。

• 可重複讀：一個事務執行過程當中看到的數據，老是跟這個事務在啓動時看到的數據是一致的，在可重複讀隔離級別下，未提交變動對其它事務也是不可見的。

• 串行化：顧名思義是對同一行記錄，「寫」會加「寫鎖」，「讀」會加「讀鎖」，當讀寫鎖衝突的時候，後訪問的事務必須等前一個事務執行完成才能繼續執行。

下邊經過一個例子來講明幾個隔離級別，先準備一張表T，其中一行的值爲1 ,按照時間順序執行兩個事務的行爲：

mysql> create table T(c int) engine=InnoDB;insert into T(c) values(1);

下邊咱們來看看不一樣的隔離級別下，事務A的各個查詢的結果，也就是V1，V2，V3的返回值分別是什麼。

• 隔離級別是「讀未提交」，則V1的值是2，這個時候雖然事務B尚未提交，可是結果已經被事務A看到了，因此V2，V3也都是2.

• 隔離級別是「讀提交」，則V1的值是1，查詢V2的時候事務B已經提交，因此事務B的更新事務A是能夠看到的，因此V２是２，Ｖ３也是２。

• 隔離級別是「可重複讀」，則V一、V2是1，V3是2，爲何V2仍是1，是由於事務在執行期看到的數據先後必須是一致的。

• 隔離級別是「串行化」，在事務B執行將1改成2的時候，會被鎖住，等事務A執行完提交後，事務B才能夠繼續執行，因此從事務A的角度來看，V一、V2值是1，V3的值是2.

在實現上，數據庫裏面會建立一個視圖，訪問的時候以視圖的邏輯爲準，在「可重複讀」隔離級別下，這個視圖是在事務啓動時建立的，整個事務存在期間都用整個視圖。在「讀提交「隔離級別下，這個視圖是在每一個SQL語句開始執行的時候建立的。」讀未提交「隔離級別下直接返回記錄上的最新值，沒有視圖概念。而」串行化「隔離級別下直接用加鎖的方式來避免並行訪問。

咱們能夠根據須要來修改MySQL的隔離級別，如咱們要將MySQL的隔離級別設置爲」讀提交「，配置的方式是，將啓動參數transaction-isolation的值設置成READ-COMMITTED,能夠用show variables來查看當前的值。

mysql> show variables like 'transaction_isolation';
+-----------------------+----------------+
| Variable_name | Value |
+-----------------------+----------------+
| transaction_isolation | READ-COMMITTED |
+-----------------------+----------------+

事務隔離的實現

上邊咱們瞭解了事務的隔離級別，咱們再來看看事務隔離具體是怎麼實現的。這裏咱們來詳細說說」可重複讀「，在MySQL中，實際上每條記錄在更新的時候都會同時記錄一條回滾操做，記錄上的最新值，經過回滾的方式均可以獲得前一個狀態的值。

假設一個值從1被依次改爲了二、三、4，在回滾日誌（undo log）裏就會有相似下邊的記錄。

當前值是4，可是在查詢這條記錄的時候，不一樣時刻啓動的事務會有不一樣的read-view，如圖中看到的，在視圖A、B、C裏面，這個記錄的值分別是一、二、4，同一條記錄在系統中能夠存在多個版本，就是數據庫的多版本併發控制（MVCC）。對於read-viewA，要想獲得1，就必須將當前值依次執行圖中全部的回滾操做獲得。

這個時候你會發現，即便如今另一個事務正在將4改成3，這個事務跟read-viewA、B、C對應的事務是不會衝突的。

回滾日誌的保留時間，在不須要的時候纔會刪除，系統判斷，沒有其餘事務線程還在使用當前版本的undo的時候，purge進程進行回收。

基於上邊的說明，咱們來討論一下大佬們常說的儘可能不使用長事務是爲何？

長事務意味着系統裏面會存在很老的事務視圖，因爲這些事務隨時可能訪問數據庫裏面的任何數據，因此這個事務提交以前，數據庫裏面它可能用到的回滾記錄都必須保留，這就致使了大量佔用內存。在MySQL5.5之前的版本，回滾日誌是和數據字典一塊兒放在ibdata文件裏的，即便長事務提交，回滾段被清理，文件也不會變小，最終每每爲了清理回滾段而重建整個庫。除了影響回滾段，長事務還會佔用鎖資源，也有可能拖垮整個庫。

事務的啓動方式

長事務的潛在風險咱們上邊已經聊過了，建議是儘量的避免，其實不少長事務，並非有意使用，都是被誤用所致，下邊咱們聊聊MySQL的事務啓動方式：

1. 顯示啓動事務語句，begin或者start transaction。配套的提交語句是commit，回滾語句是rollback。

2. set autocommit = 0，這個命令會將這個線程的自動提交關掉，意味着若是你只執行一個select語句，這個事務就啓動了，並且不會自動提交，這個事務會一直持續存在直到你主動執行commit或者rollback語句，或者斷開鏈接。

有一些客戶端鏈接框架會默認鏈接成功後執行一個set autocommit = 0命令，這就致使了接下來的查詢都在事務中，若是是長鏈接，就致使了意外的長事務。所以，建議使用set autocommit=1，經過顯式語句的方式來啓動事務。

有的朋友會糾結」多一次交互「的問題，對於一個頻繁使用事務的業務，第二種方式，每一個事務在開始時都不須要主動執行一次」begin「，減小了語句的交互次數，若是你也有這個顧慮，可使用commit work and chain語法。

autocommit爲1的狀況下，用begin顯式啓動事務，若是執行commit，則提交事務，若是執行commit work and chain，則是提交事務並開啓下一個事務，減小了begin的開銷。同時從程序開發的角度明確知道每一個語句是否處於事務中。

你能夠在 information_schema 庫的 innodb_trx 這個表中查詢長事務，好比下面這個語句，用於查找持續時間超過 60s 的事務。

select * from information_schema.innodb_trx where TIME_TO_SEC(timediff(now(),trx_started))>60

最後，咱們能夠經過嘗試回答如下幾個問題，來檢查本身的掌握程度;

1. 事務的概念是什麼?

2. mysql的事務隔離級別讀未提交, 讀已提交, 可重複讀, 串行化是什麼意思?

3. 讀已提交, 可重複讀是怎麼經過視圖構建實現的?

4. 可重複讀的使用場景舉例? 對帳的時候應該頗有用?

5. 事務隔離是怎麼經過read-view(讀視圖)實現的?

6. 併發版本控制(MCVV)的概念是什麼, 是怎麼實現的?

7. 使用長事務的弊病? 爲何使用常事務可能拖垮整個庫?

8. 事務的啓動方式有哪幾種?

9. commit work and chain的語法是作什麼用的?

10. 怎麼查詢各個表中的長事務?

11. 如何避免長事務的出現?