邏輯架構和存儲引擎
自動提交
MySQL 中默認采用的是自動提交(autocommit)模式，如下所示：
在自動提交模式下，如果沒有 start transaction 顯式地開始一個事務，那么每個 sql 語句都會被當做一個事務執行提交操作。
通過如下方式，可以關閉 autocommit;需要注意的是，autocommit 參數是針對連接的，在一個連接中修改了參數，不會對其他連接產生影響。
如果關閉了 autocommit，則所有的 sql 語句都在一個事務中，直到執行了 commit 或 rollback，該事務結束，同時開始了另外一個事務。
特殊操作
在 MySQL 中，存在一些特殊的命令，如果在事務中執行了這些命令，會馬上強制執行 commit 提交事務;如 DDL 語句(create table/drop table/alter/table)、lock tables 語句等等。
不過，常用的 select、insert、update 和 delete 命令，都不會強制提交事務。
ACID 特性
ACID 是衡量事務的四個特性：
原子性(Atomicity，或稱不可分割性)一致性(Consistency)隔離性(Isolation)持久性(Durability)按照嚴格的標准，只有同時滿足 ACID 特性才是事務;但是在各大數據庫廠商的實現中，真正滿足 ACID 的事務少之又少。
例如 MySQL 的 NDB Cluster 事務不滿足持久性和隔離性;InnoDB 默認事務隔離級別是可重復讀，不滿足隔離性;Oracle 默認的事務隔離級別為 READ COMMITTED，不滿足隔離性……
因此與其說 ACID 是事務必須滿足的條件，不如說它們是衡量事務的四個維度。
下面將詳細介紹 ACID 特性及其實現原理，為了便於理解，介紹的順序不是嚴格按照 A-C-I-D。
ACID 特性及其實現原理
原子性
定義
原子性是指一個事務是一個不可分割的工作單位，其中的操作要么都做，要么都不做。
如果事務中一個 sql 語句執行失敗，則已執行的語句也必須回滾，數據庫退回到事務前的狀態。
實現原理：undo log
在說明原子性原理之前，首先介紹一下 MySQL 的事務日志。MySQL 的日志有很多種，如二進制日志、錯誤日志、查詢日志、慢查詢日志等。
此外 InnoDB 存儲引擎還提供了兩種事務日志：
redo log(重做日志)undo log(回滾日志)其中 redo log 用於保證事務持久性;undo log 則是事務原子性和隔離性實現的基礎。
下面說回 undo log。實現原子性的關鍵，是當事務回滾時能夠撤銷所有已經成功執行的 sql 語句。
InnoDB 實現回滾，靠的是 undo log：
當事務對數據庫進行修改時，InnoDB 會生成對應的 undo log。如果事務執行失敗或調用了 rollback，導致事務需要回滾，便可以利用 undo log 中的信息將數據回滾到修改之前的樣子。undo log 屬於邏輯日志，它記錄的是 sql 執行相關的信息。當發生回滾時，InnoDB 會根據 undo log 的內容做與之前相反的工作：
對於每個 insert，回滾時會執行 delete。對於每個 delete，回滾時會執行 insert。對於每個 update，回滾時會執行一個相反的 update，把數據改回去。以 update 操作為例：當事務執行 update 時，其生成的 undo log 中會包含被修改行的主鍵(以便知道修改了哪些行)、修改了哪些列、這些列在修改前后的值等信息，回滾時便可以使用這些信息將數據還原到 update 之前的狀態。
持久性
定義
持久性是指事務一旦提交，它對數據庫的改變就應該是永久性的。接下來的其他操作或故障不應該對其有任何影響。
實現原理：redo log
redo log 和 undo log 都屬於 InnoDB 的事務日志。下面先聊一下 redo log 存在的背景。
InnoDB 作為 MySQL 的存儲引擎，數據是存放在磁盤中的，但如果每次讀寫數據都需要磁盤 IO，效率會很低。
為此，InnoDB 提供了緩存(Buffer Pool)，Buffer Pool 中包含了磁盤中部分數據頁的映射，作為訪問數據庫的緩沖：
當從數據庫讀取數據時，會首先從 Buffer Pool 中讀取，如果 Buffer Pool 中沒有，則從磁盤讀取后放入 Buffer Pool。當向數據庫寫入數據時，會首先寫入 Buffer Pool，Buffer Pool 中修改的數據會定期刷新到磁盤中(這一過程稱為刷臟)。Buffer Pool 的使用大大提高了讀寫數據的效率，但是也帶來了新的問題：如果 MySQL 宕機，而此時 Buffer Pool 中修改的數據還沒有刷新到磁盤，就會導致數據的丟失，事務的持久性無法保證。
於是，redo log 被引入來解決這個問題：當數據修改時，除了修改 Buffer Pool 中的數據，還會在 redo log 記錄這次操作;當事務提交時，會調用 fsync 接口對 redo log 進行刷盤。
如果 MySQL 宕機，重啟時可以讀取 redo log 中的數據，對數據庫進行恢復。
redo log 采用的是 WAL(Write-ahead logging，預寫式日志)，所有修改先寫入日志，再更新到 Buffer Pool，保證了數據不會因 MySQL 宕機而丟失，從而滿足了持久性要求。
既然 redo log 也需要在事務提交時將日志寫入磁盤，為什么它比直接將 Buffer Pool 中修改的數據寫入磁盤(即刷臟)要快呢?
主要有以下兩方面的原因：
刷臟是隨機 IO，因為每次修改的數據位置隨機，但寫 redo log 是追加操作，屬於順序 IO。刷臟是以數據頁(Page)為單位的，MySQL 默認頁大小是 16KB，一個 Page 上一個小修改都要整頁寫入;而 redo log 中只包含真正需要寫入的部分，無效 IO 大大減少。redo log 與 binlog
我們知道，在 MySQL 中還存在 binlog(二進制日志)也可以記錄寫操作並用於數據的恢復，但二者是有着根本的不同的。
作用不同：
redo log 是用於 crash recovery 的，保證 MySQL 宕機也不會影響持久性;binlog 是用於 point-in-time recovery 的，保證服務器可以基於時間點恢復數據，此外 binlog 還用於主從復制。層次不同：
redo log 是 InnoDB 存儲引擎實現的，而 binlog 是 MySQL 的服務器層(可以參考文章前面對 MySQL 邏輯架構的介紹)實現的，同時支持 InnoDB 和其他存儲引擎。內容不同：
redo log 是物理日志，內容基於磁盤的 Page。binlog 是邏輯日志，內容是一條條 sql。寫入時機不同：
redo log 的寫入時機相對多元。前面曾提到，當事務提交時會調用 fsync 對 redo log 進行刷盤;這是默認情況下的策略，修改 innodb_flush_log_at_trx_commit 參數可以改變該策略，但事務的持久性將無法保證。除了事務提交時，還有其他刷盤時機：如 master thread 每秒刷盤一次 redo log 等，這樣的好處是不一定要等到 commit 時刷盤，commit 速度大大加快。
binlog 在事務提交時寫入。
隔離性
定義
與原子性、持久性側重於研究事務本身不同，隔離性研究的是不同事務之間的相互影響。
隔離性是指事務內部的操作與其他事務是隔離的，並發執行的各個事務之間不能互相干擾。
嚴格的隔離性，對應了事務隔離級別中的 Serializable(可串行化)，但實際應用中出於性能方面的考慮很少會使用可串行化。
隔離性追求的是並發情形下事務之間互不干擾。簡單起見，我們僅考慮最簡單的讀操作和寫操作(暫時不考慮帶鎖讀等特殊操作)。
那么隔離性的探討，主要可以分為兩個方面：
(一個事務)寫操作對(另一個事務)寫操作的影響：鎖機制保證隔離性。(一個事務)寫操作對(另一個事務)讀操作的影響：MVCC 保證隔離性。鎖機制
首先來看兩個事務的寫操作之間的相互影響。隔離性要求同一時刻只能有一個事務對數據進行寫操作，InnoDB 通過鎖機制來保證這一點。
鎖機制的基本原理可以概括為：
事務在修改數據之前，需要先獲得相應的鎖。獲得鎖之后，事務便可以修改數據。該事務操作期間，這部分數據是鎖定的，其他事務如果需要修改數據，需要等待當前事務提交或回滾后釋放鎖。行鎖與表鎖：按照粒度，鎖可以分為表鎖、行鎖以及其他位於二者之間的鎖。
表鎖在操作數據時會鎖定整張表，並發性能較差;行鎖則只鎖定需要操作的數據，並發性能好。
但是由於加鎖本身需要消耗資源(獲得鎖、檢查鎖、釋放鎖等都需要消耗資源)，因此在鎖定數據較多情況下使用表鎖可以節省大量資源。
MySQL 中不同的存儲引擎支持的鎖是不一樣的，例如 MyIsam 只支持表鎖，而 InnoDB 同時支持表鎖和行鎖，且出於性能考慮，絕大多數情況下使用的都是行鎖。
如何查看鎖信息?有多種方法可以查看 InnoDB 中鎖的情況，例如：
select * from information_schema.innodb_locks; #鎖的概況show engine innodb status; #InnoDB整體狀態，其中包括鎖的情況下面來看一個例子：
#在事務A中執行：start transaction;update account SET balance = 1000 where id = 1;在事務B中執行：start transaction;update account SET balance = 2000 where id = 1;此時查看鎖的情況：
show engine innodb status 查看鎖相關的部分：
通過上述命令可以查看事務 24052 和 24053 占用鎖的情況;其中 lock_type 為 RECORD，代表鎖為行鎖(記錄鎖);lock_mode 為 X，代表排它鎖(寫鎖)。
除了排它鎖(寫鎖)之外，MySQL 中還有共享鎖(讀鎖)的概念。由於本文重點是 MySQL 事務的實現原理，因此對鎖的介紹到此為止。
介紹完寫操作之間的相互影響，下面討論寫操作對讀操作的影響。
臟讀、不可重復讀和幻讀
首先來看並發情況下，讀操作可能存在的三類問題。
①臟讀：當前事務(A)中可以讀到其他事務(B)未提交的數據(臟數據)，這種現象是臟讀。
舉例如下(以賬戶余額表為例)：
②不可重復讀：在事務 A 中先后兩次讀取同一個數據，兩次讀取的結果不一樣，這種現象稱為不可重復讀。
臟讀與不可重復讀的區別在於：前者讀到的是其他事務未提交的數據，后者讀到的是其他事務已提交的數據。
舉例如下：
③幻讀：在事務 A 中按照某個條件先后兩次查詢數據庫，兩次查詢結果的條數不同，這種現象稱為幻讀。
不可重復讀與幻讀的區別可以通俗的理解為：前者是數據變了，后者是數據的行數變了。
舉例如下：
事務隔離級別
sql 標准中定義了四種隔離級別，並規定了每種隔離級別下上述幾個問題是否存在。
一般來說，隔離級別越低，系統開銷越低，可支持的並發越高，但隔離性也越差。
隔離級別與讀問題的關系如下：
在實際應用中，讀未提交在並發時會導致很多問題，而性能相對於其他隔離級別提高卻很有限，因此使用較少。
可串行化強制事務串行，並發效率很低，只有當對數據一致性要求極高且可以接受沒有並發時使用，因此使用也較少。
因此在大多數數據庫系統中，默認的隔離級別是讀已提交(如 Oracle)或可重復讀(后文簡稱 RR)。
可以通過如下兩個命令分別查看全局隔離級別和本次會話的隔離級別：
InnoDB 默認的隔離級別是 RR，后文會重點介紹 RR。需要注意的是，在 SQL 標准中，RR 是無法避免幻讀問題的，但是 InnoDB 實現的 RR 避免了幻讀問題。
MVCC
RR 解決臟讀、不可重復讀、幻讀等問題，使用的是 MVCC：MVCC 全稱 Multi-Version Concurrency Control，即多版本的並發控制協議。
下面的例子很好的體現了 MVCC 的特點：在同一時刻，不同的事務讀取到的數據可能是不同的(即多版本)——在 T5 時刻，事務 A 和事務 C 可以讀取到不同版本的數據。
MVCC 最大的優點是讀不加鎖，因此讀寫不沖突，並發性能好。InnoDB 實現 MVCC，多個版本的數據可以共存，主要是依靠數據的隱藏列(也可以稱之為標記位)和 undo log。
其中數據的隱藏列包括了該行數據的版本號、刪除時間、指向 undo log 的指針等等。
當讀取數據時，MySQL 可以通過隱藏列判斷是否需要回滾並找到回滾需要的 undo log，從而實現 MVCC;隱藏列的詳細格式不再展開。
下面結合前文提到的幾個問題分別說明。
①臟讀
當事務 A 在 T3 時間節點讀取 zhangsan 的余額時，會發現數據已被其他事務修改，且狀態為未提交。
此時事務 A 讀取最新數據后，根據數據的 undo log 執行回滾操作，得到事務 B 修改前的數據，從而避免了臟讀。
②不可重復讀
當事務 A 在 T2 節點第一次讀取數據時，會記錄該數據的版本號(數據的版本號是以 row 為單位記錄的)，假設版本號為 1;當事務 B 提交時，該行記錄的版本號增加，假設版本號為 2。
當事務 A 在 T5 再一次讀取數據時，發現數據的版本號(2)大於第一次讀取時記錄的版本號(1)，因此會根據 undo log 執行回滾操作，得到版本號為 1 時的數據，從而實現了可重復讀。
③幻讀
InnoDB 實現的 RR 通過 next-keylock 機制避免了幻讀現象。
next-keylock 是行鎖的一種，實現相當於 record lock(記錄鎖) + gap lock(間隙鎖);其特點是不僅會鎖住記錄本身(record lock 的功能)，還會鎖定一個范圍(gap lock 的功能)。
當然，這里我們討論的是不加鎖讀：此時的 next-key lock 並不是真的加鎖，只是為讀取的數據增加了標記(標記內容包括數據的版本號等);准確起見姑且稱之為類 next-key lock 機制。
還是以前面的例子來說明：
當事務 A 在 T2 節點第一次讀取 0
這樣當 T5 時刻再次讀取 0
小結：概括來說，InnoDB 實現的 RR，通過鎖機制、數據的隱藏列、undo log 和類 next-key lock，實現了一定程度的隔離性，可以滿足大多數場景的需要。
不過需要說明的是，RR 雖然避免了幻讀問題，但是畢竟不是 Serializable，不能保證完全的隔離。
下面是一個例子，大家可以自己驗證一下：
一致性
基本概念
一致性是指事務執行結束后，數據庫的完整性約束沒有被破壞，事務執行的前后都是合法的數據狀態。
數據庫的完整性約束包括但不限於：
實體完整性(如行的主鍵存在且唯一)列完整性(如字段的類型、大小、長度要符合要求)外鍵約束用戶自定義完整性(如轉賬前后，兩個賬戶余額的和應該不變)實現
可以說，一致性是事務追求的最終目標：前面提到的原子性、持久性和隔離性，都是為了保證數據庫狀態的一致性。此外，除了數據庫層面的保障，一致性的實現也需要應用層面進行保障。
實現一致性的措施包括：
保證原子性、持久性和隔離性，如果這些特性無法保證，事務的一致性也無法保證。數據庫本身提供保障，例如不允許向整形列插入字符串值、字符串長度不能超過列的限制等。應用層面進行保障，例如如果轉賬操作只扣除轉賬者的余額，而沒有增加接收者的余額，無論數據庫實現的多么完美，也無法保證狀態的一致。總結
下面總結一下 ACID 特性及其實現原理：
原子性：語句要么全執行，要么全不執行，是事務最核心的特性。
事務本身就是以原子性來定義的;實現主要基於 undo log。
持久性：保證事務提交后不會因為宕機等原因導致數據丟失;實現主要基於 redo log。
隔離性：保證事務執行盡可能不受其他事務影響;
InnoDB 默認的隔離級別是 RR，RR 的實現主要基於鎖機制、數據的隱藏列、undo log 和類 next-key lock 機制。
一致性：事務追求的最終目標，一致性的實現既需要數據庫層面的保障，也需要應用層面的保障。