前面講過一條查詢語句的執(zhí)行過程一般經(jīng)過連接器，分析器，優(yōu)化器，執(zhí)行器等功能模塊，最后到達(dá)存儲引擎。接下來聊的是一條更新語句的執(zhí)行流程又是怎樣的呢？
你相信MySQL可以恢復(fù)半個月內(nèi)任意一秒的狀態(tài)嗎？ 答案是可以的。
update T set c=c+1 where ID=2
前面我們說過，在一個表上有更新的時候，跟這個表有關(guān)的查詢緩存會失效，所以這條語句就會把表 T 上所有緩存結(jié)果都清空。這也就是我們一般不建議使用查詢緩存的原因。
分析器會通過詞法和語法解析知道這是一條更新語句。優(yōu)化器決定要使用 ID 這個索引。然后，執(zhí)行器負(fù)責(zé)具體執(zhí)行，找到這一行，然后更新。
與查詢流程不一樣的是,更新的流程還會涉及到兩個很重要的日志模塊
redo log(重要日志)：redo log 是 InnoDB 引擎特有的
當(dāng)一條語句需要更新的時候，MySQL會先把需要修改的信息寫在日志上，等到空閑的時候才會去更新磁盤的信息，但是填寫日志的大小是固定的。
如圖所示：redo log 大小分為4個文件
索引從0到3,每次寫日志從0號文件開始寫，一直寫到3號文件，一直這樣循環(huán)下去。
write pos 是當(dāng)前記錄的位置，一邊寫一邊后移，寫到第 3 號文件末尾后就回到 0 號文件開頭。checkpoint 是當(dāng)前要擦除的位置，也是往后推移并且循環(huán)的，擦除記錄前要把記錄更新到數(shù)據(jù)文件。
write pos 和 checkpoint 之間的是“粉板”上還空著的部分，可以用來記錄新的操作。如果 write pos 追上 checkpoint，這時候執(zhí)行新的更新，得停下來先擦掉一些記錄，把 checkpoint 推進(jìn)一下。有了 redo log，InnoDB 就可以保證即使數(shù)據(jù)庫發(fā)生異常重啟，之前提交的記錄都不會丟失，這個能力稱為crash-safe。
bin log（歸檔日志）：MySQL 的 Server 層實現(xiàn)的，所有引擎都可以使用。
MySQL從整體來看分為兩層：一個是Server層，一個是引擎層。
redo log 是InnoDB引擎特有的日志，而Server層也有屬于自己的日志，我們稱為：binlog（歸檔日志）
為什么會有兩份日志呢？
因為最開始 MySQL 里并沒有 InnoDB 引擎。MySQL 自帶的引擎是 MyISAM，但是
MyISAM 沒有 crash-safe 的能力，binlog 日志只能用于歸檔。而 InnoDB 是另一個公司
以插件形式引入 MySQL 的，既然只依靠 binlog 是沒有 crash-safe 能力的，所以
InnoDB 使用另外一套日志系統(tǒng)——也就是 redo log 來實現(xiàn) crash-safe 能力。
這兩種日志有以下三點不同。
1. redo log 是 InnoDB 引擎特有的；binlog 是 MySQL 的 Server 層實現(xiàn)的，所有引擎都可以使用。
2. redo log 是物理日志，記錄的是“在某個數(shù)據(jù)頁上做了什么修改”；binlog 是邏輯日
志，記錄的是這個語句的原始邏輯，比如“給 ID=2 這一行的 c 字段加 1 ”。
3. redo log 是循環(huán)寫的，空間固定會用完；binlog 是可以追加寫入的。“追加寫”是指
binlog 文件寫到一定大小后會切換到下一個，并不會覆蓋以前的日志。
有了對這兩個日志的概念性理解，我們再來看執(zhí)行器和 InnoDB 引擎在執(zhí)行這個簡單的
update 語句時的內(nèi)部流程。
你可能注意到了，最后三步看上去有點“繞”，將 redo log 的寫入拆成了兩個步驟：
prepare 和 commit，這就是"兩階段提交"。
第一階段(prepare)：
? ? 首先，協(xié)調(diào)者在自身節(jié)點的日志中寫入一條的日志記錄，然后所有參與者發(fā)送消息prepare T，詢問這些參與者（包括自身），是否能夠提交這個事務(wù).
? ? 參與者在接受到這個prepare T 消息以后，會根據(jù)自身的情況，進(jìn)行事務(wù)的預(yù)處理，如果參與者能夠提交該事務(wù)，則會將日志寫入磁盤，并返回給協(xié)調(diào)者一個ready T信息，同時自身進(jìn)入預(yù)提交狀態(tài)狀態(tài)；如果不能提交該事務(wù)，則記錄日志，并返回一個not commit T信息給協(xié)調(diào)者，同時撤銷在自身上所做的數(shù)據(jù)庫改；參與者能夠推遲發(fā)送響應(yīng)的時間，但最終還是需要發(fā)送的。
第二階段(commit)：
? ? 協(xié)調(diào)者會收集所有參與者的意見，如果收到參與者發(fā)來的not commit T信息，則標(biāo)識著該事務(wù)不能提交，協(xié)調(diào)者會將Abort T? (abort終止) 記錄到日志中，并向所有參與者發(fā)送一個Abort T 信息，讓所有參與者撤銷在自身上所有的預(yù)操作；
? ? 如果協(xié)調(diào)者收到所有參與者發(fā)來prepare T信息，那么協(xié)調(diào)者會將Commit T日志寫入磁盤，并向所有參與者發(fā)送一個Commit T信息，提交該事務(wù)。若協(xié)調(diào)者遲遲未收到某個參與者發(fā)來的信息，則認(rèn)為該參與者發(fā)送了一個VOTE_ABORT信息，從而取消該事務(wù)的執(zhí)行。
? ? 參與者接收到協(xié)調(diào)者發(fā)來的Abort T信息以后，參與者會終止提交，并將Abort T 記錄到日志中；如果參與者收到的是Commit T信息，則會將事務(wù)進(jìn)行提交，并寫入記錄。
? ? 一般情況下，兩階段提交機(jī)制都能較好的運(yùn)行，當(dāng)在事務(wù)進(jìn)行過程中，有參與者宕機(jī)時，他重啟以后，可以通過詢問其他參與者或者協(xié)調(diào)者，從而知道這個事務(wù)到底提交了沒有。當(dāng)然，這一切的前提都是各個參與者在進(jìn)行每一步操作時，都會事先寫入日志。
那為什么需要使用兩階段提交呢？
1. 先寫 redo log 后寫 binlog。假設(shè)在 redo log 寫完，binlog 還沒有寫完的時候，MySQL 進(jìn)程異常重啟。由于我們前面說過的，redo log 寫完之后（redo log 寫完之后，待程序空閑的時候，會把數(shù)據(jù)更新到磁盤的），系統(tǒng)即使崩潰，仍然能夠把數(shù)據(jù)恢復(fù)回來，所以恢復(fù)后這一行 c 的值是 1。
但是由于 binlog 沒寫完就 crash 了，這時候 binlog 里面就沒有記錄這個語句。因此，之后備份日志的時候，存起來的 binlog 里面就沒有這條語句。然后你會發(fā)現(xiàn)，如果需要用這個 binlog 來恢復(fù)臨時庫的話，由于這個語句的 binlog 丟失，這個臨時庫就會少了這一次更新，恢復(fù)出來的這一行 c 的值就是 0，與原庫的值不同。
2. 先寫 binlog 后寫 redo log。如果在 binlog 寫完之后 crash，由于 redo log（磁盤沒有真正更新） 還沒寫，崩潰恢復(fù)以后這個事務(wù)無效，所以這一行 c 的值是 0。但是 binlog 里面已經(jīng)記錄了“把 c 從 0 改成 1”這個日志。所以，在之后用 binlog 來恢復(fù)的時候就多了一個事務(wù)出來，恢復(fù)出來的這一行 c 的值就是 1，與原庫的值不同
