前面講過一條查詢語句的執(zhí)行過程一般經(jīng)過連接器菩浙，分析器，優(yōu)化器句伶，執(zhí)行器等功能模塊劲蜻，最后到達(dá)存儲(chǔ)引擎。接下來聊的是一條更新語句的執(zhí)行流程又是怎樣的呢考余？
你相信MySQL可以恢復(fù)半個(gè)月內(nèi)任意一秒的狀態(tài)嗎先嬉？ 答案是可以的。
update T set c=c+1 where ID=2
前面我們說過楚堤，在一個(gè)表上有更新的時(shí)候疫蔓，跟這個(gè)表有關(guān)的查詢緩存會(huì)失效，所以這條語句就會(huì)把表 T 上所有緩存結(jié)果都清空身冬。這也就是我們一般不建議使用查詢緩存的原因鳄袍。
分析器會(huì)通過詞法和語法解析知道這是一條更新語句。優(yōu)化器決定要使用 ID 這個(gè)索引吏恭。然后拗小，執(zhí)行器負(fù)責(zé)具體執(zhí)行，找到這一行樱哼，然后更新哀九。
與查詢流程不一樣的是,更新的流程還會(huì)涉及到兩個(gè)很重要的日志模塊
redo log(重要日志)：redo log 是 InnoDB 引擎特有的
當(dāng)一條語句需要更新的時(shí)候剿配，MySQL會(huì)先把需要修改的信息寫在日志上，等到空閑的時(shí)候才會(huì)去更新磁盤的信息阅束，但是填寫日志的大小是固定的呼胚。
如圖所示：redo log 大小分為4個(gè)文件
索引從0到3,每次寫日志從0號(hào)文件開始寫，一直寫到3號(hào)文件息裸，一直這樣循環(huán)下去蝇更。
write pos 是當(dāng)前記錄的位置，一邊寫一邊后移呼盆，寫到第 3 號(hào)文件末尾后就回到 0 號(hào)文件開頭年扩。checkpoint 是當(dāng)前要擦除的位置，也是往后推移并且循環(huán)的访圃，擦除記錄前要把記錄更新到數(shù)據(jù)文件厨幻。
write pos 和 checkpoint 之間的是“粉板”上還空著的部分，可以用來記錄新的操作腿时。如果 write pos 追上 checkpoint况脆，這時(shí)候執(zhí)行新的更新，得停下來先擦掉一些記錄批糟，把 checkpoint 推進(jìn)一下格了。有了 redo log，InnoDB 就可以保證即使數(shù)據(jù)庫發(fā)生異常重啟徽鼎，之前提交的記錄都不會(huì)丟失盛末，這個(gè)能力稱為crash-safe。
bin log（歸檔日志）：MySQL 的 Server 層實(shí)現(xiàn)的纬傲，所有引擎都可以使用满败。
MySQL從整體來看分為兩層：一個(gè)是Server層肤频，一個(gè)是引擎層叹括。
redo log 是InnoDB引擎特有的日志，而Server層也有屬于自己的日志宵荒，我們稱為：binlog（歸檔日志）
為什么會(huì)有兩份日志呢汁雷？
因?yàn)樽铋_始 MySQL 里并沒有 InnoDB 引擎。MySQL 自帶的引擎是 MyISAM报咳，但是
MyISAM 沒有 crash-safe 的能力侠讯，binlog 日志只能用于歸檔。而 InnoDB 是另一個(gè)公司
以插件形式引入 MySQL 的暑刃，既然只依靠 binlog 是沒有 crash-safe 能力的厢漩，所以
InnoDB 使用另外一套日志系統(tǒng)——也就是 redo log 來實(shí)現(xiàn) crash-safe 能力。
這兩種日志有以下三點(diǎn)不同岩臣。
1. redo log 是 InnoDB 引擎特有的溜嗜；binlog 是 MySQL 的 Server 層實(shí)現(xiàn)的宵膨，所有引擎都可以使用。
2. redo log 是物理日志炸宵，記錄的是“在某個(gè)數(shù)據(jù)頁上做了什么修改”辟躏；binlog 是邏輯日
志，記錄的是這個(gè)語句的原始邏輯土全，比如“給 ID=2 這一行的 c 字段加 1 ”捎琐。
3. redo log 是循環(huán)寫的，空間固定會(huì)用完裹匙；binlog 是可以追加寫入的瑞凑。“追加寫”是指
binlog 文件寫到一定大小后會(huì)切換到下一個(gè)幻件，并不會(huì)覆蓋以前的日志拨黔。
有了對(duì)這兩個(gè)日志的概念性理解，我們?cè)賮砜磮?zhí)行器和 InnoDB 引擎在執(zhí)行這個(gè)簡(jiǎn)單的
update 語句時(shí)的內(nèi)部流程绰沥。
你可能注意到了篱蝇，最后三步看上去有點(diǎn)“繞”，將 redo log 的寫入拆成了兩個(gè)步驟：
prepare 和 commit徽曲，這就是"兩階段提交"零截。
第一階段(prepare)：
? ? 首先，協(xié)調(diào)者在自身節(jié)點(diǎn)的日志中寫入一條的日志記錄秃臣，然后所有參與者發(fā)送消息prepare T涧衙，詢問這些參與者（包括自身），是否能夠提交這個(gè)事務(wù).
? ? 參與者在接受到這個(gè)prepare T 消息以后奥此，會(huì)根據(jù)自身的情況弧哎，進(jìn)行事務(wù)的預(yù)處理，如果參與者能夠提交該事務(wù)稚虎，則會(huì)將日志寫入磁盤撤嫩，并返回給協(xié)調(diào)者一個(gè)ready T信息，同時(shí)自身進(jìn)入預(yù)提交狀態(tài)狀態(tài)蠢终；如果不能提交該事務(wù)序攘，則記錄日志，并返回一個(gè)not commit T信息給協(xié)調(diào)者寻拂，同時(shí)撤銷在自身上所做的數(shù)據(jù)庫改程奠；參與者能夠推遲發(fā)送響應(yīng)的時(shí)間，但最終還是需要發(fā)送的祭钉。
第二階段(commit)：
? ? 協(xié)調(diào)者會(huì)收集所有參與者的意見瞄沙，如果收到參與者發(fā)來的not commit T信息，則標(biāo)識(shí)著該事務(wù)不能提交，協(xié)調(diào)者會(huì)將Abort T? (abort終止) 記錄到日志中距境，并向所有參與者發(fā)送一個(gè)Abort T 信息泛粹，讓所有參與者撤銷在自身上所有的預(yù)操作；
? ? 如果協(xié)調(diào)者收到所有參與者發(fā)來prepare T信息肮疗，那么協(xié)調(diào)者會(huì)將Commit T日志寫入磁盤晶姊，并向所有參與者發(fā)送一個(gè)Commit T信息，提交該事務(wù)伪货。若協(xié)調(diào)者遲遲未收到某個(gè)參與者發(fā)來的信息们衙，則認(rèn)為該參與者發(fā)送了一個(gè)VOTE_ABORT信息，從而取消該事務(wù)的執(zhí)行碱呼。
? ? 參與者接收到協(xié)調(diào)者發(fā)來的Abort T信息以后蒙挑，參與者會(huì)終止提交，并將Abort T 記錄到日志中愚臀；如果參與者收到的是Commit T信息忆蚀，則會(huì)將事務(wù)進(jìn)行提交，并寫入記錄姑裂。
? ? 一般情況下馋袜，兩階段提交機(jī)制都能較好的運(yùn)行，當(dāng)在事務(wù)進(jìn)行過程中舶斧，有參與者宕機(jī)時(shí)欣鳖，他重啟以后，可以通過詢問其他參與者或者協(xié)調(diào)者茴厉，從而知道這個(gè)事務(wù)到底提交了沒有泽台。當(dāng)然，這一切的前提都是各個(gè)參與者在進(jìn)行每一步操作時(shí)矾缓，都會(huì)事先寫入日志怀酷。
那為什么需要使用兩階段提交呢？
1. 先寫 redo log 后寫 binlog嗜闻。假設(shè)在 redo log 寫完蜕依，binlog 還沒有寫完的時(shí)候，MySQL 進(jìn)程異常重啟泞辐。由于我們前面說過的笔横，redo log 寫完之后（redo log 寫完之后竞滓，待程序空閑的時(shí)候咐吼，會(huì)把數(shù)據(jù)更新到磁盤的），系統(tǒng)即使崩潰商佑，仍然能夠把數(shù)據(jù)恢復(fù)回來锯茄，所以恢復(fù)后這一行 c 的值是 1。
但是由于 binlog 沒寫完就 crash 了，這時(shí)候 binlog 里面就沒有記錄這個(gè)語句肌幽。因此晚碾，之后備份日志的時(shí)候，存起來的 binlog 里面就沒有這條語句喂急。然后你會(huì)發(fā)現(xiàn)格嘁，如果需要用這個(gè) binlog 來恢復(fù)臨時(shí)庫的話，由于這個(gè)語句的 binlog 丟失廊移，這個(gè)臨時(shí)庫就會(huì)少了這一次更新糕簿，恢復(fù)出來的這一行 c 的值就是 0，與原庫的值不同狡孔。
2. 先寫 binlog 后寫 redo log懂诗。如果在 binlog 寫完之后 crash，由于 redo log（磁盤沒有真正更新） 還沒寫苗膝，崩潰恢復(fù)以后這個(gè)事務(wù)無效殃恒，所以這一行 c 的值是 0。但是 binlog 里面已經(jīng)記錄了“把 c 從 0 改成 1”這個(gè)日志辱揭。所以离唐，在之后用 binlog 來恢復(fù)的時(shí)候就多了一個(gè)事務(wù)出來，恢復(fù)出來的這一行 c 的值就是 1问窃，與原庫的值不同
