架構必知：MySQL 如何實現 ACID ？

寫在前面

本文主要探討MySQL InnoDB 引擎下ACID的實現原理，對於諸如什麼是事務，隔離級別的含義等基礎知識不做過多闡述。

ACID

MySQL 作爲一個關係型數據庫，以最常見的 InnoDB 引擎來說，是如何保證 ACID 的。

• （Atomicity）原子性： 事務是最小的執行單位，不允許分割。原子性確保動作要麼全部完成，要麼完全不起作用；

• （Consistency）一致性： 執行事務前後，數據保持一致；

• （Isolation）隔離性： 併發訪問數據庫時，一個事務不被其他事務所幹擾。

• （Durability）持久性: 一個事務被提交之後。對數據庫中數據的改變是持久的，即使數據庫發生故障。

隔離性

先說說隔離性，首先是四種隔離級別。

隔離級別	說明
讀未提交	一個事務還沒提交時，它做的變更就能被別的事務看到
讀提交	一個事務提交之後，它做的變更纔會被其他事務看到
可重複讀	一個事務中，對同一份數據的讀取結果總是相同的，無論是否有其他事務對這份數據進行操作，以及這個事務是否提交。InnoDB默認級別。
串行化	事務串行化執行，每次讀都需要獲得表級共享鎖，讀寫相互都會阻塞，隔離級別最高，犧牲系統併發性。

不同的隔離級別是爲了解決不同的問題。也就是髒讀、幻讀、不可重複讀。

隔離級別	髒讀	不可重複讀	幻讀
讀未提交	可以出現	可以出現	可以出現
讀提交	不允許出現	可以出現	可以出現
可重複讀	不允許出現	不允許出現	可以出現
序列化	不允許出現	不允許出現	不允許出現

那麼不同的隔離級別，隔離性是如何實現的，爲什麼不同事物間能夠互不干擾？答案是 鎖 和 MVCC。

鎖

先來說說鎖， MySQL 有多少鎖。

粒度

從粒度上來說就是表鎖、頁鎖、行鎖。
表鎖有意向共享鎖、意向排他鎖、自增鎖等。
行鎖是在引擎層由各個引擎自己實現的。但並不是所有的引擎都支持行鎖，比如 MyISAM 引擎就不支持行鎖。

行鎖的種類

在 InnoDB 事務中，行鎖通過給索引上的索引項加鎖來實現。這意味着只有通過索引條件檢索數據，InnoDB才使用行級鎖，否則將使用表鎖。
行級鎖定同樣分爲兩種類型：共享鎖和排他鎖，以及加鎖前需要先獲得的意向共享鎖和意向排他鎖。

• 共享鎖：讀鎖，允許其他事務再加S鎖，不允許其他事務再加X鎖，即其他事務只讀不可寫。select...lock in share mode 加鎖。

• 排它鎖：寫鎖，不允許其他事務再加S鎖或者X鎖。insert、update、delete、for update加鎖。

行鎖是在需要的時候才加上的，但並不是不需要了就立刻釋放，而是要等到事務結束時才釋放。這個就是兩階段鎖協議。

行鎖的實現算法

Record Lock

單個行記錄上的鎖，總是會去鎖住索引記錄。

Gap Lock

間隙鎖，想一下幻讀的原因，其實就是行鎖只能鎖住行，但新插入記錄這個動作，要更新的是記錄之間的“間隙”。所以加入間隙鎖來解決幻讀。

Next-Key Lock

Gap Lock + Record Lock, 左開又閉。

鎖之於隔離性

大致介紹了下鎖，可以看到。有了鎖，當某事務正在寫數據時，其他事務獲取不到寫鎖，就無法寫數據，一定程度上保證了事務間的隔離。但前面說，加了寫鎖，爲什麼其他事務也能讀數據呢，不是獲取不到讀鎖嗎？

MVCC

前面說到，有了鎖，當前事務沒有寫鎖就不能修改數據，但還是能讀的，而且讀的時候，即使該行數據其他事務已修改且提交，還是可以重複讀到同樣的值。這就是MVCC，多版本的併發控制，Multi-Version Concurrency Control。

版本鏈

Innodb 中行記錄的存儲格式，有一些額外的字段：DATA_TRX_ID和DATA_ROLL_PTR。

• DATA_TRX_ID：數據行版本號。用來標識最近對本行記錄做修改的事務 id。

• DATA_ROLL_PTR：指向該行回滾段的指針。該行記錄上所有舊版本，在 undo log 中都通過鏈表的形式組織。

undo log : 記錄數據被修改之前的日誌，後面會詳細說。

ReadView

在每一條 SQL 開始的時候被創建，有幾個重要屬性：

• trx_ids: 當前系統活躍(未提交)事務版本號集合。

• low_limit_id: 創建當前 read view 時“當前系統最大事務版本號+1”。

• up_limit_id: 創建當前read view 時“系統正處於活躍事務最小版本號”

• creator_trx_id: 創建當前read view的事務版本號；

開始查詢

現在開始查詢，一個 select 過來了，找到了一行數據。

• DATA_TRX_ID <up_limit_id ：說明數據在當前事務之前就存在了，顯示。

• DATA_TRX_ID >= low_limit_id：說明該數據是在當前read view 創建後才產生的，數據不顯示。

• 不顯示怎麼辦，根據 DATA_ROLL_PTR 從 undo log 中找到歷史版本，找不到就空。

•  up_limit_id <DATA_TRX_ID <low_limit_id ：就要看隔離級別了。

RR 級別的幻讀

有了鎖和 MVCC , 事務的隔離性得到解決。這裏要引申一下，默認的 RR 的級別，解決了幻讀嗎？
幻讀通常針對的是 INSERT, 不可重複度則針對 UPDATE 。

事物 1	事物 2
begin	begin
select * from dept
-	insert into dept(name) values("A")
-	commit
update dept set name="B"
commit

我們期望是

   
   
   

    
    
    

     
     
     

      
      
      


      
      
      
id  name
     
     
     
     
     
     

      
      
      


      
      
      
1   A
     
     
     
     
     
     

      
      
      


      
      
      
2   B
     
     
     
    
    
    
   
   
   

實際卻是

   
   
   

    
    
    

     
     
     

      
      
      


      
      
      
id  name
     
     
     
     
     
     

      
      
      


      
      
      
1   B
     
     
     
     
     
     

      
      
      


      
      
      
2   B
     
     
     
    
    
    
   
   
   

其實在 MySQL 可重複讀的隔離級別中並不是完全解決了幻讀的問題，而是解決了讀數據情況下的幻讀問題。而對於修改的操作依舊存在幻讀問題，就是說 MVCC 對於幻讀的解決時不徹底的。

原子性

接着說說原子性。前文有提到 undo log ，回滾日誌。隔離性的MVCC其實就是依靠它來實現的，原子性也是。
實現原子性的關鍵，是當事務回滾時能夠撤銷所有已經成功執行的sql語句。
當事務對數據庫進行修改時，InnoDB會生成對應的 undo log；如果事務執行失敗或調用了 rollback，導致事務需要回滾，便可以利用 undo log 中的信息將數據回滾到修改之前的樣子。
undo log 屬於邏輯日誌，它記錄的是sql執行相關的信息。當發生回滾時，InnoDB 會根據 undo log 的內容做與之前相反的工作：

• 對於每個 insert，回滾時會執行 delete；

• 對於每個 delete，回滾時會執行insert；

• 對於每個 update，回滾時會執行一個相反的 update，把數據改回去。

以update操作爲例：當事務執行update時，其生成的undo log中會包含被修改行的主鍵(以便知道修改了哪些行)、修改了哪些列、這些列在修改前後的值等信息，回滾時便可以使用這些信息將數據還原到update之前的狀態。

持久性

Innnodb有很多 log，持久性靠的是 redo log。

一條SQL更新語句怎麼運行

持久性肯定和寫有關，MySQL 裏經常說到的 WAL 技術，WAL 的全稱是 Write-Ahead Logging，它的關鍵點就是先寫日誌，再寫磁盤。就像小店做生意，有個粉板，有個賬本，來客了先寫粉板，等不忙的時候再寫賬本。

redo log

redo log 就是這個粉板，當有一條記錄要更新時，InnoDB 引擎就會先把記錄寫到 redo log（並更新內存），這個時候更新就算完成了。在適當的時候，將這個操作記錄更新到磁盤裏面，而這個更新往往是在系統比較空閒的時候做，這就像打烊以後掌櫃做的事。
redo log 有兩個特點

• 大小固定，循環寫

• crash-safe

對於redo log 是有兩階段的：commit 和 prepare
如果不使用“兩階段提交”，數據庫的狀態就有可能和用它的日誌恢復出來的庫的狀態不一致.
好了，先到這裏，看看另一個。

Buffer Pool

InnoDB還提供了緩存，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宕機而丟失，從而滿足了持久性要求。
而且這樣做還有兩個優點：

• 刷髒頁是隨機 IO，redo log 順序 IO

• 刷髒頁以Page爲單位，一個Page上的修改整頁都要寫；而redo log 只包含真正需要寫入的，無效 IO 減少。

binlog

說到這，可能會疑問還有個 bin log 也是寫操作並用於數據的恢復，有啥區別呢。

• 層次：redo log 是 innoDB 引擎特有的，server 層的叫 binlog(歸檔日誌)

• 內容：redolog 是物理日誌，記錄“在某個數據頁上做了什麼修改”；binlog 是邏輯日誌，是語句的原始邏輯，如“給 ID=2 這一行的 c 字段加 1 ”

• 寫入：redolog 循環寫且寫入時機較多，binlog 追加且在事務提交時寫入

binlog 和 redo log

對於語句 update T set c=c+1 where ID=2;

1. 執行器先找引擎取 ID=2 這一行。ID 是主鍵，直接用樹搜索找到。如果 ID = 2 這一行所在數據頁就在內存中，就直接返回給執行器；否則，需要先從磁盤讀入內存，再返回。

2. 執行器拿到引擎給的行數據，把這個值加上 1，N+1，得到新的一行數據，再調用引擎接口寫入這行新數據。

3. 引擎將這行新數據更新到內存中，同時將這個更新操作記錄到 redo log 裏面，此時 redo log 處於 prepare 狀態。然後告知執行器執行完成了，隨時可以提交事務。

4. 執行器生成這個操作的 binlog，並把 binlog 寫入磁盤。

5. 執行器調用引擎的提交事務接口，引擎把剛剛寫入的 redo log 改成提交（commit）狀態，更新完成

爲什麼先寫 redo log 呢 ？

• 先 redo 後 bin : binlog 丟失，少了一次更新，恢復後仍是0。

• 先 bin 後 redo : 多了一次事務，恢復後是1。

一致性

一致性是事務追求的最終目標，前問所訴的原子性、持久性和隔離性，其實都是爲了保證數據庫狀態的一致性。
當然，上文都是數據庫層面的保障，一致性的實現也需要應用層面進行保障。
也就是你的業務，比如購買操作只扣除用戶的餘額，不減庫存，肯定無法保證狀態的一致。

總結

MySQL 都很熟， ACID 也知道是個啥，但 MySQL 的 ACID 怎麼實現的？
有時候，就像你知道了有 undo log、redo log 但可能並不太清楚爲什麼有，當知道了設計的目的，瞭解起來就會更加清晰了。

參考

MVCC 實現原理
MySQL 中的鎖
MySQL 事務中 ACID 實現原理
深入 MySQL 事務

出處：https://llc687.top/131.html

本文分享自微信公衆號 - JAVA高級架構（gaojijiagou）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。