日誌是mysql資料庫的重要組成部分，記錄著資料庫運行期間各種狀態信息。mysql日誌主要包括錯誤日誌、查詢日誌、慢查詢日誌、事務日誌、二進位日誌幾大類。作為開發，我們重點需要關注的是二進位日誌(binlog)和事務日誌(包括redo log和undo log)，本文接下來會詳細介紹這三種日誌。
binlogbinlog用於記錄資料庫執行的寫入性操作(不包括查詢)信息，以二進位的形式保存在磁碟中。binlog是mysql的邏輯日誌，並且由Server層進行記錄，使用任何存儲引擎的mysql資料庫都會記錄binlog日誌。
物理日誌：因為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：
1：每次commit的時候都要將binlog寫入磁碟；從上面可以看出，sync_binlog最安全的是設置是1，這也是MySQL 5.7.7之後版本的默認值。但是設置一個大一些的值可以提升資料庫性能，因此實際情況下也可以將值適當調大，犧牲一定的一致性來獲取更好的性能。
推薦閱讀：Java面試題拆解
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)。
搜索Java知音公眾號，回復「後端面試」，送你一份Java面試題寶典
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中，過程如下：
mysql支持三種將redo log buffer寫入redo log file的時機，可以通過innodb_flush_log_at_trx_commit參數配置，各參數值含義如下：
前面說過，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區別由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，這樣在發生錯誤時，就能回滾到事務之前的數據狀態。推薦閱讀：Java面試題拆解
同時，undo log也是MVCC(多版本並發控制)實現的關鍵，這部分內容在面試中的老大難-mysql事務和鎖，一次性講清楚！中有介紹，不再贅述。
參考https://juejin.im/post/6844903794073960455https://www.cnblogs.com/f-ck-need-u/archive/2018/05/08/9010872.htmlhttps://www.cnblogs.com/ivy-zheng/p/11094528.htmlhttps://yq.aliyun.com/articles/592937https://www.jianshu.com/p/5af73b203f2ahttps://www.jianshu.com/p/20e10ed721d0說個題外話，鳥哥是個比較喜歡折騰的程式設計師，業餘喜歡開發自己網站、小程序、App等，這些東西統統離不開伺服器！最近就圍繞伺服器的主題創建了一個微信群，喜歡玩伺服器或者想自己開發一款產品的讀者可以進來，相互學習交流！我也會時不時的帶大家擼點和伺服器相關的優惠券！不感興趣，不喜歡折騰的就沒必要湊著鬧了！