共計(jì) 1773 個(gè)字符，預(yù)計(jì)需要花費(fèi) 5 分鐘才能閱讀完成。

這期內(nèi)容當(dāng)中丸趣 TV 小編將會(huì)給大家?guī)碛嘘P(guān) MySQL 中的數(shù)據(jù)編輯過程中涉及的兩階段提交分別是什么，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

MySQL 數(shù)據(jù)庫(kù)中的兩階段提交，不知道您知道不? 這就簡(jiǎn)單的聊一聊 MySQL   數(shù)據(jù)庫(kù)中的兩階段提交，兩階段提交發(fā)生在數(shù)據(jù)變更期間(更新、刪除、新增等)，兩階段提交過程中涉及到了 MySQL 數(shù)據(jù)庫(kù)中的兩個(gè)日志系統(tǒng)：redo 日志和  binlog 文件。

redo 日志前面已經(jīng)介紹過了，就不再介紹了，簡(jiǎn)單的聊一聊 binlog 文件，binlog 是 MySQL server   層提供的二進(jìn)制文件，因此所有的存儲(chǔ)引擎都可以使用 binlog 功能，binlog   是追加寫的邏輯日志，記錄了執(zhí)行語(yǔ)句的原始邏輯，文件寫到指定大小后會(huì)切換到下一個(gè)文件繼續(xù)寫，并不會(huì)覆蓋以前寫過的日志文件。

binlog 日志文件主要用于數(shù)據(jù)恢復(fù)和集群環(huán)境下各服務(wù)器之間的數(shù)據(jù)同步，在工作中，我們誤刪了數(shù)據(jù)或者表之類，如果需要恢復(fù)的話都是利用 binlog   日志來恢復(fù)的，所以 binlog 日志是 MySQL 數(shù)據(jù)庫(kù)中比較重要的模塊。

知道這兩個(gè)日志之后，我們把重點(diǎn)回到 MySQL   數(shù)據(jù)庫(kù)兩階段提交，前面我們說了兩階段提交發(fā)生在數(shù)據(jù)變更期間，為了更好的理解兩階段提交，我們用一條更新命令來加以說明，更新語(yǔ)句如下：

mysql  update T set c=c+1 where id=2;

假設(shè)未更新前 id=2 的這行數(shù)據(jù) c 的值為 0，這條更新語(yǔ)句在 MySQL 數(shù)據(jù)庫(kù)內(nèi)部是如何執(zhí)行的呢? 在下面這張執(zhí)行流程圖：

update 語(yǔ)句執(zhí)行流程

從流程圖中可以看出，在 InnoDB 存儲(chǔ)引擎下，一條 update 語(yǔ)句在 MySQL 內(nèi)部執(zhí)行大概會(huì)經(jīng)歷下面五個(gè)步驟：

1、執(zhí)行器先找引擎取 id=2 這一行數(shù)據(jù)，如果 ID=2   這一行所在的數(shù)據(jù)頁(yè)本來就在內(nèi)存中，就直接返回給執(zhí)行器; 否則，需要先從磁盤讀入內(nèi)存，然后再返回。

2、執(zhí)行器拿到引擎給的行數(shù)據(jù)，把這個(gè)值加上 1，比如原來是 N，現(xiàn)在就是 N+1，得到新的一行數(shù)據(jù)，再調(diào)用引擎接口寫入這行新數(shù)據(jù)。

3、引擎將這行新數(shù)據(jù)更新到內(nèi)存中，同時(shí)將這個(gè)更新操作記錄到 redo log 里面，此時(shí) redo log 處于 prepare   狀態(tài)。然后告知執(zhí)行器執(zhí)行完成了，隨時(shí)可以提交事務(wù)。

4、執(zhí)行器生成這個(gè)操作的 binlog，并把 binlog 寫入磁盤。

5、執(zhí)行器調(diào)用引擎的提交事務(wù)接口，引擎把剛剛寫入的 redo log 改成提交 (commit) 狀態(tài)，更新完成。

在這五步中，注意用紅顏色標(biāo)出來的部分，redo 日志被分割成 prepare 和 commit 兩個(gè)階段提交，這個(gè)過程稱為兩階段提交，不將 redo   日志拆分成兩步提交行不行?

我們可以用反推法來證明，假設(shè)不使用兩階段提交，那么就有兩種情況，一種是先提交 redo 日志再提交 binlog 日志，另一種是先提交 binlog   日志再提交 redo 日志，一起來看看這兩種提交方式有什么問題?

先寫 redo log 后寫 binlog。假設(shè)在 redo log 寫完，binlog 還沒有寫完的時(shí)候，MySQL   進(jìn)程異常重啟。在這個(gè)過程中更新發(fā)生了異常，redo 日志是可以在數(shù)據(jù)庫(kù)發(fā)生異常是保證數(shù)據(jù)的持久性，啟動(dòng)后經(jīng)過 redo 日志數(shù)據(jù)恢復(fù)后 c 的值是 1，但是  binlog 并沒有寫完，所以在 binlog 日志文件中并沒有記錄這條更新語(yǔ)句，如果用這個(gè) binlog 日志文件來恢復(fù)臨時(shí)庫(kù)的話，恢復(fù)出來 id =2   的這行數(shù)據(jù)的 c 的值為 0，與原庫(kù)的值就不一致了。

先寫 binlog 后寫 redo log。如果在 binlog 寫完，redo 日志還沒寫，系統(tǒng)崩潰，系統(tǒng)重啟后，id=2 的這行數(shù)據(jù)的 c   的值還是為 0，但是在 binlog 日志文件中卻記錄了這次更新，如果需要用 binlog 日志文件來恢復(fù)臨時(shí)庫(kù)的話，那么 id=2 的這行數(shù)據(jù) c 的值就為  1，這樣與原庫(kù)的值就不一致了。

從這兩個(gè)假設(shè)中，我們可以看出無論先提交那個(gè)日志文件都有可能出現(xiàn)數(shù)據(jù)不一致的現(xiàn)象，日志文件兩階段提交技術(shù)就解決了 redo 日志和 binlog   日志文件記錄數(shù)據(jù)不一致的問題，從而保證了在數(shù)據(jù)恢復(fù)時(shí)數(shù)據(jù)的一致性。

上述就是丸趣 TV 小編為大家分享的 MySQL 中的數(shù)據(jù)編輯過程中涉及的兩階段提交分別是什么了，如果剛好有類似的疑惑，不妨參照上述分析進(jìn)行理解。如果想知道更多相關(guān)知識(shí)，歡迎關(guān)注丸趣 TV 行業(yè)資訊頻道。