mysql中redo log和 binlog的區(qū)別

更新時間：2022年01月29日 08:36:35 作者：初念初戀

本文主要介紹了mysql中redo log和 binlog的區(qū)別，文中通過示例代碼介紹的非常詳細(xì)，具有一定的參考價值，感興趣的小伙伴們可以參考一下

想跟大家聊聊關(guān)于 mysql 中的兩個小的知識點(diǎn)：redo log 和 binlog 。

redo log ：InnoDB 存儲引擎層方面的日志，所以如果你使用的存儲引擎不是 InnoDB 的話，那就根本談不上 redo log。

binlog ： MySQL Server 層記錄的日志，所以不管是用的什么存儲引擎，只要是 MySQL 都是會有 binlog 的存在，在做 MySQL 主從復(fù)制的時候，利用的就是 binlog。

接下來，我們就詳細(xì)來看看它們都分別做了啥？

redo log

為什么要有這個 redo log 日志文件呢？

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

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

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

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

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

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

redo log 不能一直寫吧？

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

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

因?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 是有固定大小的，所以它的空間會用完，如果用完的話，一定要進(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ù)。

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

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

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

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

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

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

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