所謂MySQL事務持久性就是事務一旦提交，就是永久性的，不會因為宕機等故障導致數據丟失（外力影響不保證，比如磁盤損害）。持久性是保證了MySQL數據庫的高可靠性（High Reliability），而不是高可用性(Hign Availability)。

MySQL的innoDB存儲引擎，使用Redo log保證了事務的持久性。當事務提交時，必須先將事務的所有日志寫入日志文件進行持久化，就是我們常說的WAL（write ahead log）機制。這樣才能保證斷電或宕機等情況發生后，已提交的事務不會丟失，這個能力稱為 crash-safe。

Redo log包括兩部分，重做日志緩沖（redo log buffer）和重做日志文件（redo log file），前者是易失的緩存，后者是持久化的文件。

舉一個事務的例子：

步驟1:begin;

步驟2:insert into t1 …r

步驟3:insert into t2 …

步驟4:commit;

這個事務的寫入過程實際拆解如下：

重點關注在這個事務提交前，將redo log的寫入拆成了兩個步驟，prepare 和 commit，這就是"兩階段提交”。那么為什么要采用兩階段提交呢？

實際上，兩階段提交是分布式系統常用的機制。MySQL使用了兩階段提交后，也是為了保證事務的持久性。Redo log 和bingo 有一個共同的數據字段，叫 XID,崩潰恢復的時候，會按順序掃描 redo log。

假設在寫入binlog前系統崩潰，那么數據庫恢復后順序掃描 redo log，碰到只有 parepare、而沒有 commit 的 redo log，就拿著 XID 去 binlog 找對應的事務，而且binlog也沒寫入，所以事務就直接回滾了。

假設在寫入binlog之后，事務提交前數據庫崩潰，那么數據庫恢復后順序掃描 redo log，碰到既有 prepare、又有 commit 的 redo log，就直接提交，保證數據不丟失。

這個事務要往兩個表中插入記錄，插入數據的過程中，生成的日志都得先寫入redo log buffer ，等到commit的時候，才真正把日志寫到 redo log 文件。（當然，這里不絕對，因為redo log buffer可能因為其他原因被迫刷新到redo log）。

而為了確保每次日志都能寫入日志文件，在每次將重做日志緩沖寫入重做日志文件后，InnoDB存儲引擎都需要調用一次fsync操作，確保寫入了磁盤。

對于redo log的持久化，可以如下圖所示。

1）先寫入redo log buffer，在藍色區域。

2）寫入redo log file，但是還沒有fsync，這時候是處于黃色的位置，處于系統緩存。

3）調用fsync，真正寫入磁盤。

為了控制 redo log 的寫入策略，InnoDB 提供了 innodb_flush_log_at_trx_commit 參數，它有三種可能取值：

設置為 0 的時候，表示每次事務提交時都只是把 redo log 留在 redo log buffer 中 ;

設置為 1 的時候，表示每次事務提交時都將 redo log 直接持久化到磁盤；

設置為 2 的時候，表示每次事務提交時都只是把 redo log 寫到 page cache。

binlog的寫入和redo log一樣，也是包括bingo cache和bingo file，同樣跟上面的三色層次類似（當然，binlog是server層的，不是存儲引擎層的），包括log buffer、文件系統page cache、hard disk。

寫入page cache 和 fsync到disk 的時機，是由參數 sync_binlog 控制的：

sync_binlog=0 的時候，表示每次提交事務都只 寫入文件系統的page cache，不 fsync；

sync_binlog=1 的時候，表示每次提交事務都會執行 fsync；

sync_binlog=N(N>1) 的時候，表示每次提交事務都寫入文件系統的page cache，但累積 N 個事務后才 fsync。（如果主機發生異常重啟，會丟失最近 N 個事務的 binlog 日志）

通常我們說MySQL的“雙 1”配置，指的就是sync_binlog和 innodb_flush_log_at_trx_commit 都設置成 1。也就是說，一個事務完整提交前，需要等待兩次刷盤，一次是 redo log（prepare 階段），一次是 binlog。

以上就是MySQL的innoDB存儲引擎，使用Redo log實現了MySQL事務持久性。除此之外，MySQL事務的其他特性也有著各自各樣的機制來實現，詳情可以觀看本站的MySQL教程，展開拓展性的學習。