前言

最近在面試，有被問到，MySQL的InnoDB引擎是如何實現事務的，又或者說是如何實現ACID這幾個特性的，當時沒有答好，所以自己總結出來，記錄一下。

事務的四大特性ACID

事務的四大特性ACID分別是，A-原子性（Atomicity），C-一致性（Consistency），I-隔離性（Isolation），D-持久性（Durability）。一致性是最終目的，原子性、隔離性、持久性是為了保證一致性所做的措施。所以我寫的順序并不是按照ACID來寫的，將一致性放到了最后，順序就變成了，ADIC。

原子性（A）

原子性是指一個事務就是一個不可分割的工作單位，要么全部都執行成功，要么全部都執行失敗，沒有中間狀態或是只執行一部分。

MySQL的InnoDB引擎是靠undo log（回滾日志）來實現的，undo log能夠保證在事務回滾時，能夠撤銷所有已經執行成功的SQL。

undo log 屬于邏輯日志，它記錄的是SQL執行相關的信息。當事務對數據庫進行修改時，InnoDB會生成與之對應的undo log。如果事務執行失敗或者調用的rollback，導致事務需要回滾，InnoDB引擎會根據undo log中的記錄，將數據回滾到之前的樣子。
例如在執行insert語句時會生成相關的delete語句的undo log。反之執行delete語句也會生成相關的insert語句的undo log。執行update語句時也是如此，不過update語句在執行undo log回滾時有可能會涉及到MVCC。主要是為了保證在執行undo log的時候的select能看到哪個版本的數據。

持久性（D）

持久性是指事務一旦提交，對數據庫的操作就是永久性的，接下來的其他操作和異常故障不應該對它有任何影響。
我們都知道MySQL的數據最終是存放在磁盤中的，所以才會有磁盤的容量大小決定數據容量的大小。但是如果對MySQL的操作都是通過讀寫磁盤來進行的話，那么光是磁盤的I/O就夠把效率大大的拉低了。

所以InnoDB為MySQL提供了緩沖池（Buffer Pool）,Buffer Pool中包含了磁盤中部分數據頁的映射。
當從數據庫讀取數據時，會先從Buffer Pool中讀取數據，如果Buffer Pool中沒有，則從磁盤讀取后放入到Buffer Pool中。
當向數據庫寫入數據時，會先寫入到Buffer Pool中，Buffer Pool中更新的數據會定期刷新到磁盤中（此過程稱為刷臟）。

雖然Buffer Pool為MySQL的讀寫提高了效率，但是卻也帶來了新的問題，那就是如果數據剛更新到Buffer Pool中還沒來得及刷新到磁盤中時，MySQL突然宕機了，這就會導致數據丟失，造成事務的持久性無法保證了。
為了解決這個緩存的一致性問題，redo log就出現了。在對Buffer Pool中的數據進行修改的時候通過redo log記錄這次操作，當事務提交時會通過fsync接口對redo log進行刷盤。

因為在事務提交時會把redo log是同步在磁盤中的，所以當MySQL出現宕機時，可以從磁盤中讀取redo log進行數據的恢復，從而保證了事務的持久性。

redo log 采用的預寫的方式記錄日志，即先記錄日志，再更新Buffer Pool，這樣就強行的保證了，數據只要保存在了redo log中就一定會存儲到磁盤中了。

這要解釋一下，redo log 也是寫磁盤，刷臟也是寫磁盤，為啥要先記錄redo log而不是直接刷臟？

主要原因就是redo log比刷臟快很多。

第一點是，redo log是追加操作日志，是順序IO；而刷臟是隨機IO，因為每次更新的數據不一定是挨著的，也就是隨機的。

第二點是，刷臟是以數據頁（Page）為單位的（即每次最少從磁盤中讀取一頁數據到內存，或者最少刷一頁數據到磁盤），MySQL默認頁大小是16KB，對一個頁上的修改，都要整個頁都刷到磁盤中；而redo log只包含真正的需要寫入磁盤的操作日志。

MySQL還有一個記錄操作的日志，叫binlog ，那么redo log和binlog又有什么區別呢？

• 第一點作用上的區別：
  

redo log是用來記錄更新緩存的，為了保證MySQL就算宕機也不會影響事務的持久性；binlog是用來記錄什么時間操作了什么，主要有時間點，可以保證將數據恢復到某個時間點，也有用于主從同步數據的。

• 第二點層次上的區別：
  

redo log是存儲引擎InnoDB實現的（MyISAM就沒有redo log），而binlog是在MySQL服務器層面存在的任何其他存儲引擎也有binlog。
存儲內容上，redo log是物理日志，基于磁盤的數據頁，binlog是邏輯日志，存儲的一條執行SQL。

• 第三點寫入時機的區別：
  

redo log 在默認情況下是在事務提交時，進行刷盤的；可以通過參數：innodb_flush_log_at_trx_commit 來改變策略，可以不用等到事務提交時才進行刷盤。
如：可以設置成每秒提交一次。
binlog是在事務提交時寫入。

隔離性（I）

原子性和持久性都是基于單個事務內部的措施，而隔離性是只多個事務之間相互隔離，互不影響的特性。
我們都知道事務的隔離級別中最嚴謹的是串行化（Serializable）,但是隔離性越高，性能就越低，所以一般不使用串行化這個隔離級別。
對于隔離性的，我們要分兩種情況進行討論：

• 一個事務中的寫操作對另一個事務中的寫操作的影響；
• 一個事務中的寫操作對另一個事務中的讀操作的影響；

首先，事務間的寫操作其實是靠MySQL的鎖機制來實現隔離的，而事務間的寫和讀操作是靠MVCC機制來實現的。

鎖機制

MySQL中的鎖主要有

按照功能分：讀鎖和寫鎖；按照作用范圍分：表級鎖和行級鎖；
還有意向鎖，間隙鎖等。

讀鎖：又稱“共享鎖”，是指多個事務可以共享一把鎖，都只能訪問數據，并不能修改。

寫鎖：又稱“排他鎖”，是不能和其他事務共享數據的，如果一個事務獲取到了一個數據的排他鎖，那么其他事務就不能再獲取該行的其他鎖，包括共享鎖和排他鎖。

表級鎖：是指會將整個表進行鎖定，性能較差，不同存儲引擎支持的鎖的粒度不同，MyISAM引擎支持表級鎖，InnoDB引擎支持表級鎖也支持行級鎖。

行級鎖：會將需要操作的相應行進行鎖定，性能好。

意向鎖：意向鎖是表級鎖，如果在一個事務已經對一個表中的某個數據加上了排他鎖或共享鎖，那么就可以加上意向鎖，這樣當下一個事務來進行鎖表的時候發現已經存在意向鎖了，就會先被阻塞，如果不加意向鎖的話，第二個事務來鎖表的時候需要一行一行的遍歷查看是否有數據已經被鎖住了。

間隙鎖：間隙鎖是為了防止產生幻讀而加的鎖，加在不存在的空閑空間，可以是兩個索引記錄之間，也可能是第一個索引記錄之前或最后一個索引之后的空間（但是并不包含當前記錄）。這樣就保證了在間隙鎖執行的時候，新增的數據會阻塞，保證了一個事務中的兩次查詢獲得的記錄數都是一致的。

Next-Key Lock：Next-Key Lock是行級鎖和間隙鎖的結合產生的鎖，因為間隙鎖是不會鎖住當前記錄的而Next-Key Lock是會將當前記錄也鎖住的。

例如：如果一個表中有三條數據分別是：