共計 1759 個字符，預計需要花費 5 分鐘才能閱讀完成。

本文丸趣 TV 小編為大家詳細介紹“MySQL 的兩階段提交機制是什么”，內容詳細，步驟清晰，細節處理妥當，希望這篇“MySQL 的兩階段提交機制是什么”文章能幫助大家解決疑惑，下面跟著丸趣 TV 小編的思路慢慢深入，一起來學習新知識吧。

MySQL 通過兩階段提交的機制，保證了 redo log 和 bin log 的邏輯一致性，進而保證了數據的不丟失以及主從庫的數據一致。

而說起兩階段提交，就不得不先介紹一下 redo log 和 bin log。

redo log

redo log 即重做日志，是 InnoDB 引擎特有的一種日志（有的面試官經常問到這一點）。

redo log 主要做什么呢？

以更新數據為例，我們知道，MySQL 的數據是存儲在磁盤上的，如果每一次更新數據，都去磁盤尋址找到要更新的數據，進行更新操作的話，這個 IO 成本是非常高的。

如果是固態硬盤還好，如果是機械硬盤，那么 MySQL 的更新性能根本無法滿足我們的業務需要。

所以，MySQL 采用了一種叫做 WAL 的技術，Write-Ahead Logging。

當更新數據時，將更新操作（即某個數據頁上做了什么修改）先寫到 redo log 里面，然后更新內存，這個更新操作就算完成了。MySQL 會在服務器空閑的時候，把 redo log 的操作記錄刷新到磁盤里，以保持數據的一致性。

需要注意的是，redo log 雖然也是磁盤上的一個文件，但是由于操作是順序寫，所以性能是非常高的。

當然了，redo log 也是有大小上限的，不可能無限制的寫入。

以上圖為例，配置了 4 個 redo log，write pos 就是代表當前記錄寫到什么位置了，而 check point 表示一個推進點，它會不斷的前移，做擦除數據的操作，以保證 redo log 可以不斷的寫入。

當然，擦除數據之前，會把 redo log 的記錄刷新到磁盤。

通過 redo log，可以保證即使 MySQL 發生異常重啟，數據也不會丟失（因為 redo log 是物理日志，可以進行重放），這個特性就叫做 crash-safe。

bin log

bin log 是 MySQL Server 提供的一種日志，叫做歸檔日志，所有引擎都可以使用 bin log。

那 bin log 和 redo log 的區別是什么呢？

1，這兩種日志的提供者不同：bin log 是由 MySQL Server 提供的，redo log 是 InnoDB 引擎特有的。

2，redo log 主要記錄的是某個數據頁做了什么修改，bin log 記錄的是語句的原始邏輯，比如更新了某一行的某個字段。

3，redo log 是循環寫的，數據會被覆蓋。bin log 是追加寫，一個文件寫滿，就寫下一個文件。

兩階段提交

介紹完了 redo log 和 bin log，我們再看一下他們兩者是如何配合完成兩階段提交的。

上圖就是一個更新數據的流程，可以看到，在更新一條數據之前，MySQL 會先將數據加載到內存，然后更新內存，開始寫 redo log。

此時，redo log 處于 prepare 狀態，等到 bin log 寫完之后，再提交事務，這一條記錄的更新操作就算完成了。

redo log prepare – 寫 bin log – redo log commit，這個流程就叫做兩階段提交。

下面我們分析一下，采用兩階段提交的好處。

情景一，redo log 處于 prepare 狀態時，如果寫 bin log 失敗了，那么更新失敗，此時 redo log 沒有 commit，bin log 也沒有記錄，兩者的狀態是一致的，沒有問題。

情景二，redo log 處于 prepare 狀態時，寫 bin log 成功，但是宕機導致 commit 失敗了。此時 bin log 產生了記錄，redo log 沒有寫入成功，數據暫時不一致。

但是不用擔心，當 MySQL 重啟時，會檢查 redo log 中處于 prepare 狀態的記錄。在 redo log 中，記錄了一個叫做 XID 的字段，這個字段在 bin log 中也有記錄，MySQL 會通過這個 XID，如果在 bin log 中找到了，那么就 commit 這個 redo log，如果沒有找到，說明 bin log 其實沒有寫成功，就放棄提交。

通過這樣的機制，保證了 redo log 和 bin log 的一致性。

讀到這里，這篇“MySQL 的兩階段提交機制是什么”文章已經介紹完畢，想要掌握這篇文章的知識點還需要大家自己動手實踐使用過才能領會，如果想了解更多相關內容的文章，歡迎關注丸趣 TV 行業資訊頻道。