提到事務，你肯定不陌生，和資料庫打交道的時候，我們總是會用到事務。最經典的例子就是轉賬，你要給朋友小王轉 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);
在實現上，資料庫裡面會建立乙個檢視，訪問的時候以檢視的邏輯結果為準。在「可重複讀」隔離級別下，這個檢視是在事務啟動時建立的，整個事務存在期間都用這個檢視。在「讀提交」隔離級別下，這個檢視是在每個 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我給你留乙個問題吧。你現在知道了系統裡面應該避免長事務，如果你是業務開發負責人同時也是資料庫負責人，你會有什麼方案來避免出現或者處理這種情況呢？
問題是一天一備跟一周一備的對比。
好處是「最長恢復時間」更短。
在一天一備的模式裡，最壞情況下需要應用一天的 binlog。比如，你每天 0 點做一次全量備份，而要恢復出乙個到昨天晚上 23 點的備份。
一周一備最壞情況就要應用一周的 binlog 了。
當然這個是有成本的，因為更頻繁全量備份需要消耗更多儲存空間，所以這個 rto 是成本換來的，就需要你根據業務重要性來評估了。
MySQL 實戰 2 事務隔離
目錄2.5 事務的啟動方式 3 問題自我總結 2.1 資料庫多事務同時執行時可能產生的問題 髒讀 dirty read 幻讀 phantom read 不可重複讀 non repeatable read 隔離級別越高效率越低 2.2 隔離級別 讀未提交 read uncommitted 讀提交 re...
3 MySQL 事物隔離級別及讀寫鎖
一 mysql 事務隔離級別 讀未提交 read uncommitted 乙個事務可以讀到其他事務沒有提交的資料，會出現髒讀 不可重複讀 幻讀 讀已提交 read committed 乙個事務只能讀到另乙個已提交的資料修改過的資料，並且其他事務沒隊該資料進行一次修改並提交後，該事務都能查詢到最新值，...
mysql 3 事務隔離
1.事務就是要保證一組資料庫操作，要麼全部成功，要麼全部失敗 2.在 mysql 中，事務支援是在引擎層實現的 3.mysql 是乙個支援多引擎的系統，但並不是所有的引擎都支援事務。比如 mysql 原生的 myisam 引擎就不支援事務，這也是 myisam 被 innodb 取代的重要原因之一。...