使用數據庫，總會使用到事務。最經典的例子就是銀行的轉賬業務。轉賬過程會有一系列的操作：比如餘額查詢，加減法、更新餘額等，這些操作必須保證是一體的，不然在你查詢餘額之後，加減法之前，在這個時間差在做一次查詢轉賬的操作，這樣的話銀行的業務就會亂套了。這時就要用到事務的概念了。
簡單來說，事務是保證一組數據操作要麼全部成功，要麼全部失敗。在MySQL中，事務的支持在引擎層實現的。MySQL是支持多引擎的，但不是所有的引擎都支持事務，MySQL原生的引擎MYISAM就不支持事務。這也是MYISAM被InnoDB取代的原因之一。
隔離性和隔離級別
提到事務，肯定會想到ACID(Atomicity,Consistency,Isolation,Durability,即原子性，一致性，隔離性，持久性)。
原子性：數據庫的操作要麼全部成功，要麼全部失敗；
一致性：事務必須使數據從一個一致性狀態轉換成另一個一致性狀態，也就是說事務執行之前和執行之後的必須取出一致性狀態；
隔離性：當併發訪問數據庫是，一個事務訪問數據庫不能被另外一個事務干擾；
持久性：事務一旦提交，對 數據的修改是永久的，即使數據庫系統出現故障也不會丟失提交事務的操作；
當數據庫有多個事務同時執行的時候，就可能出現髒讀（dirty read），不可重複讀（nonrepeatable read），幻讀（phantom read）的問題，就有了隔離級別的概念。
在說隔離級別之前，首先要知道，你隔離的越嚴實，效率就會越低，因此很多時候，我們就要在兩者之間找一個平衡點。SQL標準事務隔了級別有：讀未提交（read uncommitted），讀提交（read committed），可重複讀（repeatable read），串行化（serializable）。
1、讀未提交：一個事務還沒有提交時，它做的變更就能被看到。
2、讀提交：一個事務提交之後，它做的變更才能被看到。
3、可重複讀：一個事務執行過程中看到的數據，總是跟事務啓動時看到的數據是一致的。當然在可重複讀級別下，未提交變更對其他事務也是不可見的。
4、串行化：對於同一行數據，讀會加讀鎖，寫會加寫鎖。當出現讀寫衝突的時候，後訪問的事務必須等前一個事務執行完成才能執行。
其中讀提交與可重複讀比較難理解，下面用一個例子來說明幾種隔離級別。
mysql> create table T(c int) engine=InnoDB;
insert into T(c) values(1);
在不同的隔離級別下面，事務A會有哪些不同的返回結果：
1、若隔離級別是讀未提交，則V1的值就是2，這是事務B雖然沒有提交，但是結果已經被A看到了，所以V2、V3都是2。
2、若隔離界別是讀提交，V1是1，V2是2，事務B的更新在提交後才能被A看到。所以V3也是2
3、若隔離級別是可重複讀，V1、V2是1，V3是2，之所以V2是1，遵循的就是事務在執行期間看到的數據前後必須是一直的。
4、若隔離級別是串行化，則在事務執行將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 的事務啓動方式有以下幾種：
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