Mysql三大日志-binlog、redo log和undo log
日志是 mysql 數據庫的重要組成部分，記錄着數據庫運行期間各種狀態信息。mysql日志主要包括錯誤日志、查詢日志、慢查詢日志、事務日志、二進制日志幾大類。作為開發，我們重點需要關注的是二進制日志( binlog )和事務日志(包括redo log和undo log）本人主要接下來會詳細介紹着三種日志。
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的時候會讓日志暴漲且它相對於statment格式日志要更占用更大的空間。 -
MIXED：基於STATMENT和ROW兩種模式的混合復制(mixed-based replication, MBR)，一般的復制使用STATEMENT模式保存binlog，對於STATEMENT模式無法復制的操作使用ROW模式保存binlog
redo log
為什么需要redo log
我們都知道，事務的四大特性里面有一個是持久性 ，具體來說就是只要事務提交成功，那么對數據庫做的修改就被永久保存下來了，不可能因為任何原因再回到原來的狀態。那么mysql是如何保證一致性的呢？最簡單的做法是在每次事務提交的時候，將該事務涉及修改的數據頁全部刷新到磁盤中。但是這么做會有嚴重的性能問題，主要體現在兩個方面：
-
因為
Innodb是以頁為單位進行磁盤交互的，而一個事務很可能只修改一個數據頁里面的幾個字節，這個時候將完整的數據頁刷到磁盤的話，太浪費資源了！ -
一個事務可能涉及修改多個數據頁，並且這些數據頁在物理上並不連續，使用隨機IO寫入性能太差！
因此mysql設計了redo log ， 具體來說就是只記錄事務對數據頁做了哪些修改，且該日志(redo log是基於WAL機制運行的)，它先是將數據頁的變化給記錄下來用來保證事務的持久性，二是
可以做自動故障恢復，三是可以減少臟頁立即刷盤所帶來的磁盤I/O性能問題(有了日志優先寫的策略可以使得內存中的臟頁不總是急於刷盤)，4.redo log 日志是flush操作是順序I/O操作且相對而言文件更小是順序IO)。
redo log基本概念
redo log 包括兩部分：一個是內存中的日志緩沖( redo log buffer )，另一個是磁盤上的日志文件( redo log file )，其中關於這兩個參數在innodb存儲引擎中都是有相應的配置所對應。執行流程是：當mysql 每執行一條 DML 語句，先將記錄寫入 redo log buffer，后續某個時間點再一次性將多個操作記錄(這里就是要看兩個參數：1是innodb_flush_log_at_trx_commit,2是看innodb_flush_method參數)寫到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 參數配置，各參數值含義如下：
| 參數值 | 含義 |
|---|---|
| 0（延遲寫） | 表示當事務提交時，不做日志寫入操作，而是每秒鍾將log buffer中的數據寫入日志文件並flush磁盤一次； |
| 1（實時寫，實時刷） | 每次事務的提交都會引起redo日志文件寫入、flush磁盤的操作，確保了事務的ACID； |
| 2（實時寫，延遲刷） | 每次事務提交引起寫入日志文件的動作,但每秒鍾完成一次flush磁盤操作。 |
這里還有另外一個參數：innodb_flush_method(該參數主要控制內存中的臟頁和redo log 日志的刷新策略)，該參數主要有以下幾個值：
| 參數值 | 含義 |
|---|---|
fsync |
（1）在數據頁需要持久化時，首先將數據寫入OS buffer中，然后由os決定什么時候寫入磁盤 （2）在redo buffuer需要持久化時，首先將數據寫入OS buffer中，然后由os決定什么時候寫入磁盤 但，如果innodb_flush_log_at_trx_commit=1的話，日志還是直接每次commit直接寫入磁盤 |
O_DIRECT |
（1）在數據頁需要持久化時，直接寫入磁盤，不用在經過OS buffer這一層 |
| 后續補充其他 刷新策略 |
。。。 |
總結：這兩個參數一般是相互配合地進行使用的，一般都是要配置的，如下圖所示：
說明：在配置號innodb_flush_Method之后，這時nnodb_flush_log_at_trx_commit參數0和2的磁盤刷新的性能都高於1，因為它們都是在正常的情況下是減少磁盤I/O刷新的次數，從而提高Mysql性能，1是每提交一次事務就會調用fsync()進行刷盤因此它的磁盤I/O利用率會遠遠高於前兩種(在系統負載比較高的情況下，這樣對數據庫的性能有很大的影響)，但是它的好處是不會丟失事務，即使丟失也是只會丟失一個事務，但是，0的話如果數據庫宕機后，它就會丟失一秒的事務(一秒內可能對韻數據庫來說已經提交了很多事務了),然后2的話，當數據庫宕機后，它的事務是不會丟失的，只有當服務器宕機了，它才會丟失1秒內的事務。
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 log | binlog |
| --- | --- | --- |
| 文件大小 | 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(多版本並發控制)實現的關鍵。