點擊藍色“JavaKeeper”關注我喲

加個“星標”，一起成長，做牛逼閃閃的技術人

Keeper導讀：日志是mysql數據庫的重要組成部分，記錄著數據庫運行期間各種狀態信息。mysql日志主要包括錯誤日志、查詢日志、慢查詢日志、事務日志、二進制日志幾大類。作為開發，我們重點需要關注的是二進制日志(binlog)和事務日志(包括redo log和undo log)，本文接下來會詳細介紹這三種日志。

來源：https://sourl.cn/EtrNut

全文共 4222?字，閱讀需要 8 分鐘

binlog

binlog用于記錄數據庫執行的寫入性操作(不包括查詢)信息，以二進制的形式保存在磁盤中。binlog是mysql的邏輯日志，并且由Server層進行記錄，使用任何存儲引擎的mysql數據庫都會記錄binlog日志。

邏輯日志：可以簡單理解為記錄的就是sql語句。

物理日志：因為mysql數據最終是保存在數據頁中的，物理日志記錄的就是數據頁變更。

binlog是通過追加的方式進行寫入的，可以通過max_binlog_size參數設置每個binlog文件的大小，當文件大小達到給定值之后，會生成新的文件來保存日志。

binlog使用場景

在實際應用中，binlog的主要使用場景有兩個，分別是主從復制和數據恢復。

主從復制：在Master端開啟binlog，然后將binlog發送到各個Slave端，Slave端重放binlog從而達到主從數據一致。

數據恢復：通過使用mysqlbinlog工具來恢復數據。

binlog刷盤時機

對于InnoDB存儲引擎而言，只有在事務提交時才會記錄biglog，此時記錄還在內存中，那么biglog是什么時候刷到磁盤中的呢？mysql通過sync_binlog參數控制biglog的刷盤時機，取值范圍是0-N：

• 0：不去強制要求，由系統自行判斷何時寫入磁盤；
• 1：每次commit的時候都要將binlog寫入磁盤；
• N：每N個事務，才會將binlog寫入磁盤。

從上面可以看出，sync_binlog最安全的是設置是1，這也是MySQL 5.7.7之后版本的默認值。但是設置一個大一些的值可以提升數據庫性能，因此實際情況下也可以將值適當調大，犧牲一定的一致性來獲取更好的性能。

binlog日志格式

binlog日志有三種格式，分別為STATMENT、ROW和MIXED。

在 MySQL 5.7.7之前，默認的格式是STATEMENT，MySQL 5.7.7之后，默認值是ROW。日志格式通過binlog-format指定。

• STATMENT 基于SQL語句的復制(statement-based replication, SBR)，每一條會修改數據的sql語句會記錄到binlog中。優點：不需要記錄每一行的變化，減少了binlog日志量，節約了IO, 從而提高了性能；缺點：在某些情況下會導致主從數據不一致，比如執行sysdate()、slepp()等。
• ROW 基于行的復制(row-based replication, RBR)，不記錄每條sql語句的上下文信息，僅需記錄哪條數據被修改了。優點：不會出現某些特定情況下的存儲過程、或function、或trigger的調用和觸發無法被正確復制的問題；缺點：會產生大量的日志，尤其是alter table的時候會讓日志暴漲
• MIXED 基于STATMENT和ROW兩種模式的混合復制(mixed-based replication, MBR)，一般的復制使用STATEMENT模式保存binlog，對于STATEMENT模式無法復制的操作使用ROW模式保存binlog

redo log

為什么需要redo log

我們都知道，事務的四大特性里面有一個是持久性，具體來說就是只要事務提交成功，那么對數據庫做的修改就被永久保存下來了，不可能因為任何原因再回到原來的狀態。那么mysql是如何保證一致性的呢？最簡單的做法是在每次事務提交的時候，將該事務涉及修改的數據頁全部刷新到磁盤中。但是這么做會有嚴重的性能問題，主要體現在兩個方面：

因為Innodb是以頁為單位進行磁盤交互的，而一個事務很可能只修改一個數據頁里面的幾個字節，這個時候將完整的數據頁刷到磁盤的話，太浪費資源了！

一個事務可能涉及修改多個數據頁，并且這些數據頁在物理上并不連續，使用隨機IO寫入性能太差！

因此mysql設計了redo log，具體來說就是只記錄事務對數據頁做了哪些修改，這樣就能完美地解決性能問題了(相對而言文件更小并且是順序IO)。

redo log基本概念

redo log包括兩部分：一個是內存中的日志緩沖(redo log buffer)，另一個是磁盤上的日志文件(redo log file)。mysql每執行一條DML語句，先將記錄寫入redo log buffer，后續某個時間點再一次性將多個操作記錄寫到redo log file。這種先寫日志，再寫磁盤的技術就是MySQL里經常說到的WAL(Write-Ahead Logging) 技術。

在計算機操作系統中，用戶空間(user space)下的緩沖區數據一般情況下是無法直接寫入磁盤的，中間必須經過操作系統內核空間(kernel space)緩沖區(OS Buffer)。因此，redo log buffer寫入redo log file實際上是先寫入OS Buffer，然后再通過系統調用fsync()將其刷到redo log file中，過程如下：

img

mysql支持三種將redo log buffer寫入redo log file的時機，可以通過innodb_flush_log_at_trx_commit參數配置，各參數值含義如下：

參數值含義

0(延遲寫)	事務提交時不會將redo log buffer中日志寫入到os buffer，而是每秒寫入os buffer并調用fsync()寫入到redo log file中。也就是說設置為0時是(大約)每秒刷新寫入到磁盤中的，當系統崩潰，會丟失1秒鐘的數據。
1(實時寫，實時刷)	事務每次提交都會將redo log buffer中的日志寫入os buffer并調用fsync()刷到redo log file中。這種方式即使系統崩潰也不會丟失任何數據，但是因為每次提交都寫入磁盤，IO的性能較差。
2(實時寫，延遲刷)	每次提交都僅寫入到os buffer，然后是每秒調用fsync()將os buffer中的日志寫入到redo log file。

img

redo log記錄形式

前面說過，redo log實際上記錄數據頁的變更，而這種變更記錄是沒必要全部保存，因此redo log實現上采用了大小固定，循環寫入的方式，當寫到結尾時，會回到開頭循環寫日志。如下圖：

同時我們很容易得知，在innodb中，既有redo log需要刷盤，還有數據頁也需要刷盤，redo log存在的意義主要就是降低對數據頁刷盤的要求。在上圖中，write pos表示redo log當前記錄的LSN(邏輯序列號)位置，check point表示數據頁更改記錄刷盤后對應redo log所處的LSN(邏輯序列號)位置。write pos到check point之間的部分是redo log空著的部分，用于記錄新的記錄；check point到write pos之間是redo log待落盤的數據頁更改記錄。當write pos追上check point時，會先推動check point向前移動，空出位置再記錄新的日志。

啟動innodb的時候，不管上次是正常關閉還是異常關閉，總是會進行恢復操作。因為redo log記錄的是數據頁的物理變化，因此恢復的時候速度比邏輯日志(如binlog)要快很多。重啟innodb時，首先會檢查磁盤中數據頁的LSN，如果數據頁的LSN小于日志中的LSN，則會從checkpoint開始恢復。還有一種情況，在宕機前正處于checkpoint的刷盤過程，且數據頁的刷盤進度超過了日志頁的刷盤進度，此時會出現數據頁中記錄的LSN大于日志中的LSN，這時超出日志進度的部分將不會重做，因為這本身就表示已經做過的事情，無需再重做。

redo log與binlog區別

redo logbinlog

文件大小	redo log的大小是固定的。	binlog可通過配置參數max_binlog_size設置每個binlog文件的大小。
實現方式	redo log是InnoDB引擎層實現的，并不是所有引擎都有。	binlog是Server層實現的，所有引擎都可以使用 binlog日志
記錄方式	redo log 采用循環寫的方式記錄，當寫到結尾時，會回到開頭循環寫日志。	binlog 通過追加的方式記錄，當文件大小大于給定值后，后續的日志會記錄到新的文件上
適用場景	redo log適用于崩潰恢復(crash-safe)	binlog適用于主從復制和數據恢復

由binlog和redo log的區別可知：binlog日志只用于歸檔，只依靠binlog是沒有crash-safe能力的。但只有redo log也不行，因為redo log是InnoDB特有的，且日志上的記錄落盤后會被覆蓋掉。因此需要binlog和redo log二者同時記錄，才能保證當數據庫發生宕機重啟時，數據不會丟失。

undo log

數據庫事務四大特性中有一個是原子性，具體來說就是 原子性是指對數據庫的一系列操作，要么全部成功，要么全部失敗，不可能出現部分成功的情況。實際上，原子性底層就是通過undo log實現的。undo log主要記錄了數據的邏輯變化，比如一條INSERT語句，對應一條DELETE的undo log，對于每個UPDATE語句，對應一條相反的UPDATE的undo log，這樣在發生錯誤時，就能回滾到事務之前的數據狀態。同時，undo log也是MVCC(多版本并發控制)實現的關鍵。

總結

以上是生活随笔為你收集整理的binlog日志_MySQL三大日志binlog、redo log和undo log的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。