MySQL事務之ACID特性的實現原理的詳細介紹（圖文）

這篇文章帶給大家的內容是關於MySQL事務之ACID特性的實現原理的詳細介紹（圖文），有一定的參考價值，有需要的朋友可以參考一下，希望對你有幫助。

事務是MySQL等關係型資料庫區別於NoSQL的重要方面，是保證資料一致性的重要手段。 本文將先介紹與MySQL事務相關的基礎概念，然後再介紹事務的ACID特性，並分析其實作原理。

MySQL博大精深，文章疏漏之處在所難免，歡迎批評指正。

一、基礎概念

事務（Transaction）是存取和更新資料庫的程式執行單元；事務中可能包含一個或多個sql語句，這些語句要么都執行，要嘛都不執行。作為一個關係型資料庫，MySQL支援事務，本文介紹基於MySQL5.6。

首先回顧MySQL事務的基礎知識。 （推薦課程：MySQL影片教學）

1.邏輯架構與儲存引擎

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

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

（2）第二層：伺服器層，負責查詢語句的解析、最佳化、快取以及內建函數的實作、預存程序等。

（3）第三層：儲存引擎，負責MySQL中資料的儲存與擷取。 MySQL中伺服器層不管理事務，事務是由儲存引擎實現的。 MySQL支援事務的儲存引擎有InnoDB、NDB Cluster等，其中InnoDB的使用最廣泛；其他儲存引擎不支援事務，如MyIsam、Memory等。

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

2. 提交和回滾

典型的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指令，都不會強制提交交易。

3. ACID特性

ACID是衡量事務的四個特性：

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

• 一致性（Consistency）

• 隔離性（Isolation）

• 持久性（Durability）

依照嚴格的標準，只有同時滿足ACID特性才是事務；但是在各大資料庫廠商的實作中，真正滿足ACID的事務少之又少。例如MySQL的NDB Cluster交易不滿足持久性和隔離性；InnoDB預設交易隔離等級是可重複讀取，不滿足隔離性；Oracle預設的交易隔離等級為READ COMMITTED，不滿足隔離性…因此與其說ACID是事務必須滿足的條件，不如說它們是衡量事務的四個維度。

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

二、原子性

1. 定義

原子性是指一個事務是一個不可分割的工作單位，其中的操作要麼都做，要麼都不做；如果事務中一個sql語句執行失敗，則已執行的語句也必須回滾，資料庫退回到事務前的狀態。

2. 實作原理：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之前的狀態。

三、持久性

1. 定義

持久性是指交易一旦提交，它對資料庫的改變就應該是永久性的。接下來的其他操作或故障不應該對其有任何影響。

2. 實作原則：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中修改的資料寫入磁碟(即刷髒)要快呢？主要有以下兩方面的原因：

（1）刷髒是隨機IO，因為每次修改的資料位置隨機，但寫redo log是追加操作，屬於順序IO。

（2）刷髒是以資料頁（Page）為單位的，MySQL預設頁大小是16KB，一個Page上一個小修改都要整頁寫入；而redo log中只包含真正需要寫入的部分，無效IO大大減少。

3. redo log與binlog

我們知道，在MySQL中還存在binlog(二進位日誌)也可以記錄寫入操作並用於資料的恢復，但二者是有著根本的不同的：

（1）作用不同：redo log是用於crash recovery的，保證MySQL宕機也不會影響持久性；binlog是用於point-in-time recovery的，保證伺服器可以基於時間點恢復數據，此外binlog也用於主從複製。

（2）層次不同：redo log是InnoDB儲存引擎實現的，而binlog是MySQL的伺服器層(可以參考文章前面對MySQL邏輯架構的介紹)實現的，同時支援InnoDB和其他存儲引擎。

（3）內容不同：redo log是實體日誌，內容基於磁碟的Page；binlog是邏輯日誌，內容是一則sql。

（4）寫入時機不同：binlog在事務提交時寫入；redo log的寫入時機相對多元：

• 前面曾提到：當事務提交時會呼叫fsync對redo log進行刷盤；這是預設的策略，修改innodb_flush_log_at_trx_commit參數可以改變該策略，但交易的持久性將無法保證。

• 除了事务提交时，还有其他刷盘时机：如master thread每秒刷盘一次redo log等，这样的好处是不一定要等到commit时刷盘，commit速度大大加快。

四、隔离性

1. 定义

与原子性、持久性侧重于研究事务本身不同，隔离性研究的是不同事务之间的相互影响。隔离性是指，事务内部的操作与其他事务是隔离的，并发执行的各个事务之间不能互相干扰。严格的隔离性，对应了事务隔离级别中的Serializable (可串行化)，但实际应用中出于性能方面的考虑很少会使用可串行化。

隔离性追求的是并发情形下事务之间互不干扰。简单起见，我们仅考虑最简单的读操作和写操作(暂时不考虑带锁读等特殊操作)，那么隔离性的探讨，主要可以分为两个方面：

• (一个事务)写操作对(另一个事务)写操作的影响：锁机制保证隔离性

• (一个事务)写操作对(另一个事务)读操作的影响：MVCC保证隔离性

2. 锁机制

首先来看两个事务的写操作之间的相互影响。隔离性要求同一时刻只能有一个事务对数据进行写操作，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事务的实现原理，因此对锁的介绍到此为止，后续会专门写文章分析MySQL中不同锁的区别、使用场景等，欢迎关注。

介绍完写操作之间的相互影响，下面讨论写操作对读操作的影响。

3. 脏读、不可重复读和幻读

首先来看并发情况下，读操作可能存在的三类问题：

（1）脏读：当前事务(A)中可以读到其他事务(B)未提交的数据（脏数据），这种现象是脏读。举例如下（以账户余额表为例）：

（2）不可重复读：在事务A中先后两次读取同一个数据，两次读取的结果不一样，这种现象称为不可重复读。脏读与不可重复读的区别在于：前者读到的是其他事务未提交的数据，后者读到的是其他事务已提交的数据。举例如下：

（3）幻读：在事务A中按照某个条件先后两次查询数据库，两次查询结果的条数不同，这种现象称为幻读。不可重复读与幻读的区别可以通俗的理解为：前者是数据变了，后者是数据的行数变了。举例如下：

4. 事务隔离级别

SQL标准中定义了四种隔离级别，并规定了每种隔离级别下上述几个问题是否存在。一般来说，隔离级别越低，系统开销越低，可支持的并发越高，但隔离性也越差。隔离级别与读问题的关系如下：

在實際應用中，讀取未提交在並發時會導致很多問題，而效能相對於其他隔離等級提高卻很有限，因此使用較少。 可串列化強制交易串列，並發效率很低，只有當對資料一致性要求極高且可以接受沒有並發時使用，因此使用也較少。因此在大多數資料庫系統中，預設的隔離等級是讀取已提交(如Oracle)或可重複讀取（後文簡稱RR）。

可以透過以下兩個指令分別查看全域隔離等級和本次會話的隔離等級：

InnoDB預設的隔離等級是RR，後文會重點介紹RR。要注意的是，在SQL標準中，RR是無法避免幻讀問題的，但InnoDB實作的RR避免了幻讀問題。

5. MVCC

RR解決髒讀、不可重複讀、幻讀等問題，使用的是MVCC：MVCC全名為Multi-Version Concurrency Control，也就是多版本的並發控制協定。以下的例子很好的體現了MVCC的特點：在同一時刻，不同的事務讀取到的資料可能是不同的(即多版本)－在T5時刻，事務A和事務C可以讀取到不同版本的數據。

MVCC最大的優點是讀不加鎖，因此讀寫不衝突，並發效能好。 InnoDB實作MVCC，多個版本的資料可以共存，主要是依賴資料的隱藏列(也可以稱之為標記位)和undo log。其中資料的隱藏列包含了該行資料的版本號、刪除時間、指向undo log的指標等等；當讀取資料時，MySQL可以透過隱藏列判斷是否需要回溯並找到回溯所需的undo log，從而實現MVCC；隱藏列的詳細格式不再展開。

下面結合前文提到的幾個問題分別說明。

（1）髒讀

當事務A在T3時間節點讀取zhangsan的餘額時，會發現資料已被其他事務修改，且狀態為未提交。此時事務A讀取最新數據後，根據數據的undo log執行回溯操作，得到事務B修改前的數據，從而避免了髒讀。

（2）不可重複讀取

當事務A在T2節點第一次讀取資料時，會記錄該資料的版本號（數據的版本號是以row為單位記錄的），假設版本號為1；當事務B提交時，該行記錄的版本號增加，假設版本號為2；當事務A在T5再一次讀取資料時，發現資料的版本號（2）大於第一次讀取時記錄的版本號（1），因此會根據undo log執行回溯操作，得到版本號為1時的數據，從而實現了可重複讀取。

（3）幻讀

InnoDB實作的RR透過next-key lock機制避免了幻讀現象。

next-key lock是行鎖定的一種，實作相當於record lock(記錄鎖定) gap lock(間隙鎖定)；其特點是不僅會鎖定記錄本身(record lock的功能)，還會鎖定一個範圍(gap lock的功能)。 當然，這裡我們討論的是不加鎖讀：此時的next-key lock並不是真的加鎖，只是為讀取的資料增加了標記（標記內容包括資料的版本號等）；準確起見姑且稱為類next-key lock機制。還是以前面的例子來說明：

當事務A在T2節點第一次讀取0

6. 總結

概括來說，InnoDB實現的RR，透過鎖定機制、資料的隱藏列、undo log和類別next-key lock，實現了一定程度的隔離性，可以滿足大多數場景的需求。不過要說明的是，RR雖然避免了幻讀問題，但畢竟不是Serializable，不能保證完全的隔離，下面是一個例子，大家可以自己驗證一下。

五、一致性

1. 基本概念

一致性是指交易執行結束後，資料庫的完整性限制沒有被破壞，事務執行的前後都是合法的資料狀態。 資料庫的完整性限制包括但不限於：實體完整性（如行的主鍵存在且唯一）、列完整性（如欄位的類型、大小、長度要符合要求）、外鍵約束、使用者自訂完整性（如轉帳前後，兩個帳戶餘額的和應該不變）。

2. 實現

可以說，一致性是事務追求的最終目標：前面提到的原子性、持久性和隔離性，都是為了保證資料庫狀態的一致性。此外，除了資料庫層面的保障，一致性的實現也需要應用層面來保障。

實現一致性的措施包括：

• 保證原子性、持久性和隔離性，如果這些特性無法保證，交易的一致性也無法保證

• 資料庫本身提供保障，例如不允許向整形列插入字串值、字串長度不能超過列的限制等

• 應用程式層面進行保障，例如如果轉帳作業只扣除轉帳者的餘額，而沒有增加接收者的餘額，無論資料庫實現的多麼完美，也無法保證狀態的一致

六、總結

以下總結ACID特性及其實作原理：

• 原子性：語句要麼全執行，要麼全不執行，是事務最核心的特性，事務本身就是以原子性來定義的；實作主要基於undo log

• 持久性：保證交易提交後不會因為宕機等原因導致資料遺失；實作主要基於redo log

• 隔離性：確保事務執行盡可能不受其他交易影響；InnoDB預設的隔離等級是RR，RR的實作主要基於鎖定機制、資料的隱藏列、undo log和類別next- key lock機制

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

#

以上是MySQL事務之ACID特性的實現原理的詳細介紹（圖文）的詳細內容。更多資訊請關注PHP中文網其他相關文章！