事務就是要保證一組數據庫操作，要麼全部成功，要麼全部失敗。事務支持是在引擎層實現的，Mysql原生的MyISAM引擎不支持事務，InnoDB支持事務，這就是爲何MyISAM會被InnoDB取代。
事務的四個特性：ACID（Atomicity、Consistency、Isolation、Durability即原子性、一致性、隔離性、持久性）
隔離性與隔離級別
多個事務同時執行，有可能發生髒讀（dirty read）、不可重複讀（non-repeatable read）、幻讀（phantom read），於是隔離級別的概念誕生
隔離越嚴實，效率會越低，我們要在其中找一個平衡點。
SQL標準的事務隔離級別包括：讀未提交（read uncommitted）、讀提交（read committed）、可重複讀（repeatable read）和串行化（serializable ）
- 讀未提交是指，一個事務還沒提交時，它做的變更就能被別的事務看到。
- 讀提交是指，一個事務提交之後，它做的變更纔會被其他事務看到。
- 可重複讀是指，一個事務執行過程中看到的數據，總是跟這個事務在啓動時看到的數據是一致的。當然在可重複讀隔離級別下，未提交變更對其他事務也是不可見的。
- 串行化，顧名思義是對於同一行記錄，“寫”會加“寫鎖”，“讀”會加“讀鎖”。當出現讀寫鎖衝突的時候，後訪問的事務必須等前一個事務執行完成，才能繼續執行。
例子
不同的隔離級別下，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數據庫的默認隔離級別是“讀提交”（InnoDB是可重複讀），當從Oracle遷移到MySQL的應用，爲保證數據庫隔離級別的一致，要將MySQL的隔離級別設置爲“讀提交”。
什麼時候需要可重複讀呢？
假設你在管理一個個人銀行賬戶表。一個表存了每個月月底的餘額，一個表存了賬單明細。這時候你要做數據校對，也就是判斷上個月的餘額和當前餘額的差額，是否與本月的賬單明細一致。你一定希望在校對過程中，即使有用戶發生了一筆新的交易，也不影響你的校對結果。這時候使用“可重複讀”隔離級別就很方便。事務啓動時的視圖可以認爲是靜態的，不受其他事務更新的影響。
事務隔離的實現（可重複讀）
在MySQL中，每條記錄在更新時都會同時記錄一條回滾操作。記錄上的最新值，通過回滾操作，都可以得到前一個狀態的值。
假設一個值從1被按順序改成了2、3、4，在回滾日誌裏面就會有類似下面的記錄。
當前值爲4，但從不同時刻啓動的事務，得到的是不同的read-view。在視圖A、B、C裏，記錄的值分別是1、2、4，同一條記錄在系統中可以存在多個版本，就是數據庫的多版本併發控制（MVCC）。對於read-view A，要得到1，就必須將當前值依次執行圖中所有的回滾操作得到。
即使此時有另一個事務將4改成5，事務與A、B、C對應的事務不衝突。
回滾日誌在當系統沒有比這個回滾日誌更早的read-view時被刪除
對此，儘量不要使用長事務，長事務意味着系統裏面會存在很老的事務視圖，由於這些事務隨時可能訪問數據庫裏面的任何數據，所以這個事務提交之前，數據庫裏面它可能用到的回滾記錄都必須保留，這就會導致大量佔用存儲空間。
除了對回滾段的影響，長事務還佔用鎖資源，也可能拖垮整個庫
事務的啓動方式
- 顯式啓動事務語句， begin 或 start transaction。提交語句是commit，回滾語句是rollback。
- set autocommit=0，這個命令會將這個線程的自動提交關掉。意味着如果你只執行一個select語句，這個事務就啓動了，而且並不會自動提交。這個事務持續存在直到你主動執行commit 或 rollback 語句，或者斷開連接。