提到事務，你肯定不陌生，和數據庫打交道的時候，我們總是會用到事務。最經典的例子就是轉賬，你要給朋友小王轉100塊錢，而此時你的銀行卡只有100塊錢。
轉賬過程具體到程序里會有一系列的操作，比如查詢余額、做加減法、更新余額等，這些操作必須保證是一體的，不然等程序查完之后，還沒做減法之前，你這100塊錢，完全可以借着這個時間差再查一次，然后再給另外一個朋友轉賬，如果銀行這么整，不就亂了么？這時就要用到“事務”這個概念了。
簡單來說，事務就是要保證一組數據庫操作，要么全部成功，要么全部失敗。在MySQL中，事務支持是在引擎層實現的。你現在知道，MySQL是一個支持多引擎的系統，但並不是所有的引擎都支持事務。比如MySQL原生的MyISAM引擎就不支持事務，這也是MyISAM被InnoDB取代的重要原因之一。
今天的文章里，我將會以InnoDB為例，剖析MySQL在事務支持方面的特定實現，並基於原理給出相應的實踐建議，希望這些案例能加深你對MySQL事務原理的理解。
隔離性與隔離級別
提到事務，你肯定會想到ACID（Atomicity、Consistency、Isolation、Durability，即原子性、一致性、隔離性、持久性），今天我們就來說說其中I，也就是“隔離性”。
當數據庫上有多個事務同時執行的時候，就可能出現臟讀（dirty read）、不可重復讀（non-repeatable read）、幻讀（phantom 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的值是2。事務B的更新在提交后才能被A看到。所以， V3的值也是2。
- 若隔離級別是“可重復讀”，則V1、V2是1，V3是2。之所以V2還是1，遵循的就是這個要求：事務在執行期間看到的數據前后必須是一致的。
- 若隔離級別是“串行化”，則在事務B執行“將1改成2”的時候，會被鎖住。直到事務A提交后，事務B才可以繼續執行。所以從A的角度看， V1、V2值是1，V3的值是2。
在實現上，數據庫里面會創建一個視圖，訪問的時候以視圖的邏輯結果為准。在“可重復讀”隔離級別下，這個視圖是在事務啟動時創建的，整個事務存在期間都用這個視圖。在“讀提交”隔離級別下，這個視圖是在每個SQL語句開始執行的時候創建的。這里需要注意的是，“讀未提交”隔離級別下直接返回記錄上的最新值，沒有視圖概念；而“串行化”隔離級別下直接用加鎖的方式來避免並行訪問。
我們可以看到在不同的隔離級別下，數據庫行為是有所不同的。Oracle數據庫的默認隔離級別其實就是“讀提交”，因此對於一些從Oracle遷移到MySQL的應用，為保證數據庫隔離級別的一致，你一定要記得將MySQL的隔離級別設置為“讀提交”。
配置的方式是，將啟動參數transaction-isolation的值設置成READ-COMMITTED。你可以用show variables來查看當前的值。
mysql> show variables like 'transaction_isolation';
+-----------------------+----------------+
| Variable_name | Value |
+-----------------------+----------------+
| transaction_isolation | READ-COMMITTED |
+-----------------------+----------------+
總結來說，存在即合理，哪個隔離級別都有它自己的使用場景，你要根據自己的業務情況來定。我想你可能會問那什么時候需要“可重復讀”的場景呢？我們來看一個數據校對邏輯的案例。
假設你在管理一個個人銀行賬戶表。一個表存了每個月月底的余額，一個表存了賬單明細。這時候你要做數據校對，也就是判斷上個月的余額和當前余額的差額，是否與本月的賬單明細一致。你一定希望在校對過程中，即使有用戶發生了一筆新的交易，也不影響你的校對結果。
這時候使用“可重復讀”隔離級別就很方便。事務啟動時的視圖可以認為是靜態的，不受其他事務更新的影響。
事務隔離的實現
理解了事務的隔離級別，我們再來看看事務隔離具體是怎么實現的。這里我們展開說明“可重復讀”。
在MySQL中，實際上每條記錄在更新的時候都會同時記錄一條回滾操作。記錄上的最新值，通過回滾操作，都可以得到前一個狀態的值。
假設一個值從1被按順序改成了2、3、4，在回滾日志里面就會有類似下面的記錄。
當前值是4，但是在查詢這條記錄的時候，不同時刻啟動的事務會有不同的read-view。如圖中看到的，在視圖A、B、C里面，這一個記錄的值分別是1、2、4，同一條記錄在系統中可以存在多個版本，就是數據庫的多版本並發控制（MVCC）。對於read-view A，要得到1，就必須將當前值依次執行圖中所有的回滾操作得到。
同時你會發現，即使現在有另外一個事務正在將4改成5，這個事務跟read-view A、B、C對應的事務是不會沖突的。
你一定會問，回滾日志總不能一直保留吧，什么時候刪除呢？答案是，在不需要的時候才刪除。也就是說，系統會判斷，當沒有事務再需要用到這些回滾日志時，回滾日志會被刪除。
什么時候才不需要了呢？就是當系統里沒有比這個回滾日志更早的read-view的時候。
基於上面的說明，我們來討論一下為什么建議你盡量不要使用長事務。
長事務意味着系統里面會存在很老的事務視圖。由於這些事務隨時可能訪問數據庫里面的任何數據，所以這個事務提交之前，數據庫里面它可能用到的回滾記錄都必須保留，這就會導致大量占用存儲空間。
在MySQL 5.5及以前的版本，回滾日志是跟數據字典一起放在ibdata文件里的，即使長事務最終提交，回滾段被清理，文件也不會變小。我見過數據只有20GB，而回滾段有200GB的庫。最終只好為了清理回滾段，重建整個庫。
除了對回滾段的影響，長事務還占用鎖資源，也可能拖垮整個庫，這個我們會在后面講鎖的時候展開。
事務的啟動方式
如前面所述，長事務有這些潛在風險，我當然是建議你盡量避免。其實很多時候業務開發同學並不是有意使用長事務，通常是由於誤用所致。MySQL的事務啟動方式有以下幾種：
-
顯式啟動事務語句， begin 或 start transaction。配套的提交語句是commit，回滾語句是rollback。
-
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
小結
這篇文章里面，我介紹了MySQL的事務隔離級別的現象和實現，根據實現原理分析了長事務存在的風險，以及如何用正確的方式避免長事務。希望我舉的例子能夠幫助你理解事務，並更好地使用MySQL的事務特性。
我給你留一個問題吧。你現在知道了系統里面應該避免長事務，如果你是業務開發負責人同時也是數據庫負責人，你會有什么方案來避免出現或者處理這種情況呢？
你可以把你的思考和觀點寫在留言區里，我會在下一篇文章的末尾和你討論這個問題。感謝你的收聽，也歡迎你把這篇文章分享給更多的朋友一起閱讀。
上期問題時間
在上期文章的最后，我給你留下的問題是一天一備跟一周一備的對比。
好處是“最長恢復時間”更短。
在一天一備的模式里，最壞情況下需要應用一天的binlog。比如，你每天0點做一次全量備份，而要恢復出一個到昨天晚上23點的備份。
一周一備最壞情況就要應用一周的binlog了。
系統的對應指標就是 @尼古拉斯·趙四 @慕塔 提到的RTO（恢復目標時間）。
當然這個是有成本的，因為更頻繁全量備份需要消耗更多存儲空間，所以這個RTO是成本換來的，就需要你根據業務重要新來評估了。