日志是mysql資料庫的重要組成部分，記錄着資料庫運作期間各種狀态資訊。mysql日志主要包括錯誤日志、查詢日志、慢查詢日志、事務日志、二進制日志幾大類。作為開發，我們重點需要關注的是二進制日志(binlog)和事務日志(包括redo log和undo log)，本文接下來會詳細介紹這三種日志。
binlog用于記錄資料庫執行的寫入性操作(不包括查詢)資訊，以二進制的形式儲存在磁盤中。binlog是mysql的邏輯日志，并且由server層進行記錄，使用任何存儲引擎的mysql資料庫都會記錄binlog日志。
邏輯日志：可以簡單了解為記錄的就是sql語句。
實體日志：因為mysql資料最終是儲存在資料頁中的，實體日志記錄的就是資料頁變更。
binlog是通過追加的方式進行寫入的，可以通過max_binlog_size參數設定每個binlog檔案的大小，當檔案大小達到給定值之後，會生成新的檔案來儲存日志。
在實際應用中，binlog的主要使用場景有兩個，分别是主從複制和資料恢複。
主從複制：在master端開啟binlog，然後将binlog發送到各個slave端，slave端重放binlog進而達到主從資料一緻。
資料恢複：通過使用mysqlbinlog工具來恢複資料。
對于innodb存儲引擎而言，隻有在事務送出時才會記錄biglog，此時記錄還在記憶體中，那麼biglog是什麼時候刷到磁盤中的呢？mysql通過sync_binlog參數控制biglog的刷盤時機，取值範圍是0-n：
0：不去強制要求，由系統自行判斷何時寫入磁盤；
1：每次commit的時候都要将binlog寫入磁盤；
n：每n個事務，才會将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
我們都知道，事務的四大特性裡面有一個是持久性，具體來說就是隻要事務送出成功，那麼對資料庫做的修改就被永久儲存下來了，不可能因為任何原因再回到原來的狀态。那麼mysql是如何保證一緻性的呢？最簡單的做法是在每次事務送出的時候，将該事務涉及修改的資料頁全部重新整理到磁盤中。但是這麼做會有嚴重的性能問題，主要展現在兩個方面：
因為innodb是以頁為機關進行磁盤互動的，而一個事務很可能隻修改一個資料頁裡面的幾個位元組，這個時候将完整的資料頁刷到磁盤的話，太浪費資源了！
一個事務可能涉及修改多個資料頁，并且這些資料頁在實體上并不連續，使用随機io寫入性能太差！
是以mysql設計了redo log，具體來說就是隻記錄事務對資料頁做了哪些修改，這樣就能完美地解決性能問題了(相對而言檔案更小并且是順序io)。
搜尋java知音公衆号，回複“後端面試”，送你一份java面試題寶典
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，這時超出日志進度的部分将不會重做，因為這本身就表示已經做過的事情，無需再重做。
由binlog和redo log的差別可知：binlog日志隻用于歸檔，隻依靠binlog是沒有crash-safe能力的。但隻有redo log也不行，因為redo log是innodb特有的，且日志上的記錄落盤後會被覆寫掉。是以需要binlog和redo log二者同時記錄，才能保證當資料庫發生當機重新開機時，資料不會丢失。
資料庫事務四大特性中有一個是原子性，具體來說就是 原子性是指對資料庫的一系列操作，要麼全部成功，要麼全部失敗，不可能出現部分成功的情況。
實際上，原子性底層就是通過undo log實作的。undo log主要記錄了資料的邏輯變化，比如一條insert語句，對應一條delete的undo log，對于每個update語句，對應一條相反的update的undo log，這樣在發生錯誤時，就能復原到事務之前的資料狀态。
同時，undo log也是mvcc(多版本并發控制)實作的關鍵，這部分内容在面試中的老大難-mysql事務和鎖，一次性講清楚！中有介紹，不再贅述。
-end-