本文將首先介紹 MySQL 事務相關的基礎概念，然後介紹事務的 ACID 特性，並分析其實現原理。MySQL 博大精深，文章疏漏之處在所難免，歡迎批評指正。

事務（Transaction）是訪問和更新資料庫的程式執行單元；事務中可能包含一個或多個 sql 陳述句，這些陳述句要麼都執行，要麼都不執行。

作為一個關係型資料庫，MySQL 支援事務，本文介紹基於 MySQL 5.6。首先回顧一下 MySQL 事務的基礎知識。

如上圖所示，MySQL 伺服器邏輯架構從上往下可以分為三層：

• 第一層：處理客戶端連線、授權認證等。

• 第二層：伺服器層，負責查詢陳述句的解析、最佳化、快取以及內建函式的實現、儲存過程等。

• 第三層：儲存引擎，負責 MySQL 中資料的儲存和提取。MySQL 中伺服器層不管理事務，事務是由儲存引擎實現的。

  MySQL 支援事務的儲存引擎有 InnoDB、NDB Cluster 等，其中 InnoDB 的使用最為廣泛；其他儲存引擎不支援事務，如 MyIsam、Memory 等。

如無特殊說明，後文中描述的內容都是基於 InnoDB。

典型的 MySQL 事務是如下操作的：

start transaction;
……  #一條或多條sql陳述句
commit;

其中 start transaction 標識事務開始，commit 提交事務，將執行結果寫入到資料庫。

如果 sql 陳述句執行出現問題，會呼叫 rollback，回滾所有已經執行成功的 sql 陳述句。當然，也可以在事務中直接使用 rollback 陳述句進行回滾。

自動提交

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 是衡量事務的四個特性：

• 原子性（Atomicity，或稱不可分割性）

• 一致性（Consistency）

• 隔離性（Isolation）

• 永續性（Durability）

按照嚴格的標準，只有同時滿足 ACID 特性才是事務；但是在各大資料庫廠商的實現中，真正滿足 ACID 的事務少之又少。

例如 MySQL 的 NDB Cluster 事務不滿足永續性和隔離性；InnoDB 預設事務隔離級別是可重覆讀，不滿足隔離性；Oracle 預設的事務隔離級別為 READ COMMITTED，不滿足隔離性……

因此與其說 ACID 是事務必須滿足的條件，不如說它們是衡量事務的四個維度。

下麵將詳細介紹 ACID 特性及其實現原理，為了便於理解，介紹的順序不是嚴格按照 A-C-I-D。

定義

原子性是指一個事務是一個不可分割的工作單位，其中的操作要麼都做，要麼都不做。

如果事務中一個 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 機制。

• 一致性：事務追求的最終標的，一致性的實現既需要資料庫層面的保障，也需要應用層面的保障。

參考文獻：

• 《MySQL 技術內幕：InnoDB 儲存引擎》

• 《高效能 MySQL》

• 《MySQL 運維內參》

• https://dev.mysql.com/doc/refman/5.6/en/glossary.html#glos_acid

• https://dev.mysql.com/doc/refman/5.6/en/innodb-next-key-locking.html

• http://blog.sina.com.cn/s/blog_499740cb0100ugs7.html

• https://mp.weixin.qq.com/s/2dwGBTmu_da2x-HiHlN0vw

• http://www.cnblogs.com/chenpingzhao/p/5065316.html

• https://juejin.im/entry/5ba0a254e51d450e735e4a1f

• http://hedengcheng.com/?p=771

已推薦到看一看

你的朋友可以在“發現”-“看一看”看到你認為好看的文章。

取消
推薦

我知道了

已取消，“好看”想法已同步刪除

知道了