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

binlog

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

• 邏輯日志：可以簡單理解為記錄的就是sql語句 。
• 物理日志：mysql 數據最終是保存在數據頁中的，物理日志記錄的就是數據頁變更 。

binlog 是通過追加的方式進行寫入的，可以通過max_binlog_size 參數設置每個 binlog文件的大小，當文件大小達到給定值之后，會生成新的文件來保存日志。binlog使用場景在實際應用中， binlog 的主要使用場景有兩個，分別是 主從復制 和 數據恢復 。

1. 主從復制 ：在 Master 端開啟 binlog ，然后將 binlog發送到各個 Slave 端， Slave 端重放 binlog 從而達到主從數據一致。
2. 數據恢復 ：通過使用 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是如何保證一致性的呢？最簡單的做法是在每次事務提交的時候，將該事務涉及修改的數據頁全部刷新到磁盤中。但是這么做會有嚴重的性能問題，主要體現在兩個方面：

1. 因為 Innodb 是以 頁 為單位進行磁盤交互的，而一個事務很可能只修改一個數據頁里面的幾個字節，這個時候將完整的數據頁刷到磁盤的話，太浪費資源了！
2. 一個事務可能涉及修改多個數據頁，并且這些數據頁在物理上并不連續，使用隨機IO寫入性能太差！

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

redo log 包括兩部分：一個是內存中的日志緩沖( redo log buffer )，另一個是磁盤上的日志文件( redo logfile)。

mysql 每執行一條 DML 語句，先將記錄寫入 redo log buffer，后續某個時間點再一次性將多個操作記錄寫到 redo log file。這種 先寫日志，再寫磁盤 的技術就是 MySQL
里經常說到的 WAL(Write-Ahead Logging) 技術。在計算機操作系統中，用戶空間( user space )下的緩沖區數據一般情況下是無法直接寫入磁盤的，中間必須經過操作系統內核空間( kernel space )緩沖區( OS Buffer )。因此， redo log buffer 寫入 redo logfile 實際上是先寫入 OS Buffer ，然后再通過系統調用 fsync() 將其刷到 redo log file

image

image

image

image

image

由 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(多版本并發控制)實現的關鍵。