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