這里，我們可以舉個(gè)例子，現(xiàn)在我們想對(duì)數(shù)據(jù)庫的數(shù)據(jù)進(jìn)行修改操作，現(xiàn)在一條 update 語句過來，一般 update 操作都伴隨著查詢的操作，得先找到這條數(shù)據(jù)，然后再進(jìn)行更新操作對(duì)吧。

如果數(shù)據(jù)量比較小還好，很快就能找到并且更新完畢，但是如果數(shù)據(jù)量比較大，里面有一億條數(shù)據(jù)，怎么辦？而且更新操作肯定是要寫到磁盤上去的，那這中間的 IO 成本呢？

如果我有好幾十條 update 語句先后更新呢？這樣想的話，你就能想到，就這些操作，成本就高的不行，那能不能降低一下這些成本呢？

這時(shí)候，redo log 就起到作用了。當(dāng)有一條記錄更新的時(shí)候， InnoDB 引擎就會(huì)先把記錄寫到 redo log 里面去，同時(shí)更新內(nèi)存，這樣就算是更新這條數(shù)據(jù)成功了。

但是此時(shí)，它并沒有更新到磁盤上去對(duì)吧？別擔(dān)心， InnoDB 會(huì)在恰當(dāng)?shù)臅r(shí)候，把這條及記錄更新到磁盤上去。

這樣的思想或者技術(shù)，有個(gè)專有名詞: WAL 技術(shù)，也就是 WriteAheadLogging ，核心就是先寫日志，再寫磁盤。

redo log 不能一直寫吧？

redo log 的大小是固定的，前面的內(nèi)容會(huì)被覆蓋，一旦寫滿，就會(huì)觸發(fā) redo log 到磁盤的同步，以便騰出空間記錄后面的修改。

數(shù)據(jù)庫發(fā)生宕機(jī)或者重啟，數(shù)據(jù)也將不會(huì)丟失。

因?yàn)橛辛?redo log ，之前提交的記錄都還在，只需要根據(jù) redo log 里面的記錄進(jìn)行相應(yīng)恢復(fù)就可以了。

binlog

binlog 是 MySQL Server 層的記錄日志。

redo log 和 binlog 的區(qū)別：

redo log 是 InnoDB 引擎特有的； binlog 是 MySQL 的 Server 層實(shí)現(xiàn)的，所有的引擎都是可以的。
redo log 是物理日志，記錄的是”在 XXX 頁上做了 XXX 修改”；binlog 是邏輯日志，比如” 給 id = 2 這一行的 c 字段加 1”。
redo log 是有固定大小的，所以它的空間會(huì)用完，如果用完的話，一定要進(jìn)行一些寫入磁盤的操作才可以繼續(xù)；binlog 是可以追加寫入的，也就是 binlog 沒有空間的概念，一直寫就行了。

binlog 以事件的形式記錄了所有的 DDL 和 DML 語句（因?yàn)樗涗浀氖遣僮鞫皇菙?shù)據(jù)值，屬于邏輯日志），可以用來做主從復(fù)制和數(shù)據(jù)恢復(fù)。

在開啟了 binlog 功能的情況下，我們可以把 binlog 導(dǎo)出成 SQL 語句，把所有的操作重放一遍，來實(shí)現(xiàn)數(shù)據(jù)的恢復(fù)。

有了這兩個(gè)日志之后，我們來看一下一條更新語句是怎么執(zhí)行的（redo 不能一次寫入了）：

例如一條語句：update user set name='小馬' where id=1;

先查詢到這條數(shù)據(jù)，如果有緩存，也會(huì)用到緩存。
把 name 改成小馬，然后調(diào)用引擎的 API 接口，寫入這一行數(shù)據(jù)到內(nèi)存，同時(shí)記錄 redo log。這時(shí) redo log 進(jìn)入 prepare 狀態(tài)，然后告訴執(zhí)行器，執(zhí)行完成了，可以隨時(shí)提交。
執(zhí)行器收到通知后記錄 binlog，然后調(diào)用存儲(chǔ)引擎接口，設(shè)置 redo log為 commit 狀態(tài)。
更新完成。

你能發(fā)現(xiàn) redo log 竟然是先 prepare 狀態(tài)，等 binlog 寫完之后，才是 commit 狀態(tài)，這種方式就叫”兩階段提交”。為什么會(huì)有這種方式呢？

redo log 和 binlog 都可以用于表示事務(wù)的提交狀態(tài)，而兩階段提交就是讓這兩個(gè)狀態(tài)保持邏輯上的一致。

可以假設(shè)一下，如果不采用這種方式，而是就先寫 redo log ，再寫 binlog ，會(huì)怎樣？如果在寫 binlog 時(shí)，發(fā)生了異常，更新操作已經(jīng)到 redo log 中了，但是此時(shí) binlog 并沒有進(jìn)行更新，是不是出現(xiàn)了數(shù)據(jù)不一致？

先寫 binlog 再寫 redo log 也是一樣的道理。所以，在寫時(shí)，先讓 redo log 處于 prepare 狀態(tài)，等 binlog 寫完之后，再讓 redo log 處于 commit 狀態(tài)，這樣就保持了邏輯上的一致。