在MySQL資料庫和InnoDB存盤引擎中，有很多種檔案，如：引數檔案、日志檔案、socket檔案、pid檔案、MySQL表結構檔案、存盤引擎檔案，

本節重點關注日志檔案，MySQL的復制、事務等重要功能都和日志檔案相關，日志檔案主要包括錯誤日志檔案、二進制日志檔案、慢查詢日志檔案、查詢日志檔案、重做日志檔案等，其中重做日志檔案是InnoDB引擎檔案，

1、日志檔案介紹

1.1、錯誤日志（error log）

錯誤日志檔案對MySQL的啟動、運行、關閉程序進行了記錄，是定位MySQL問題的第一把鑰匙，

1.2、慢查詢日志（slow query log）

慢查詢日志是用來記錄執行時間超過 long_query_time 這個變數定義的時長的查詢陳述句，通過慢查詢日志，可以查找出哪些查詢陳述句的執行效率很低，以便進行優化，

1.3、一般查詢日志（general log）

一般查詢日志記錄了所有對MySQL資料庫請求的資訊，無論請求是否正確執行，

默認情況下，general log 是關閉的，開啟通用查詢日志會增加很多磁盤 I/O， 所以如非出于除錯排錯目的，不建議開啟通用查詢日志，

1.4、二進制日志（bin log）

關于二進制日志，它記錄了資料庫所有執行的DDL和DML陳述句（除了資料查詢陳述句select、show等），以事件形式記錄并保存在二進制檔案中，

• log_bin：指定binlog是否開啟及檔案名稱，
• server_id：指定服務器唯一ID，開啟binlog 必須設定此引數，
• binlog_format：指定binlog模式，建議設定為ROW，
• max_binlog_size：控制單個二進制日志大小，當前日志檔案大小超過此變數時，執行切換動作，
• expire_logs_days：控制二進制日志檔案保留天數，默認值為0，表示不自動洗掉，可設定為0~99，

二進制日志檔案是非常重要的日志檔案，建議開啟，二進制日志主要有這么幾個作用：

• 恢復：利用二進制檔案恢復資料，原理是取出日志的操作記錄，重新執行

• 復制：和恢復原理類似，一般分為主庫和從庫，
• 審計: 通過觀察二進制檔案，可以判斷是否存在對資料庫有危險性的操作，

1.5、重做日志（redo log）

對于InnoDB，重做日志至關重要，因為它們記錄了對于InnoDB存盤引擎的事務日志，

當實體或介質失敗時，如資料庫由于所在主機斷電導致實體失敗，InnoDB存盤引擎就會恢復到斷電前的時刻，以此來保證資料的完整性，

InnoDB引擎對資料的更新，是先將更新記錄寫入redo log日志，然后會在系統空閑的時候或者是按照設定的更新策略再將日志中的內容更新到磁盤之中，這就是所謂的預寫式技術（Write Ahead logging），這種技術可以大大減少IO操作的頻率，提升資料重繪的效率，

寫入重做日志檔案也不是直接寫，而是先寫入一個重做日志緩沖，然后按照一定的條件順序寫入日志檔案，

redo log日志的大小是固定的，為了能夠持續不斷的對更新記錄進行寫入，在redo log日志中設定了兩個標志位置，checkpoint和write_pos，分別表示記錄擦除的位置和記錄寫入的位置，redo log日志的資料寫入示意圖可見下圖，

當write_pos標志到了日志結尾時，會從結尾跳至日志頭部進行重新回圈寫入，所以redo log的邏輯結構并不是線性的，而是可看作一個圓周運動，write_pos與checkpoint中間的空間可用于寫入新資料，寫入和擦除都是往后推移，回圈往復的，

當write_pos追上checkpoint時，表示redo log日志已經寫滿，這時不能繼續執行新的資料庫更新陳述句，需要停下來先洗掉一些記錄，執行checkpoint規則騰出可寫空間，

checkpoint規則：checkpoint觸發后，將buffer中臟資料頁和臟日志頁都刷到磁盤，

同樣是記錄事務日志，和bin log有什么不同呢？

• bin log會記錄所有與資料庫有關的日志記錄，包括InnoDB、MyISAM等存盤引擎的日志，而redo log只記InnoDB存盤引擎的日志，

• 記錄的內容不同，bin log記錄的是關于一個事務的具體操作內容，即該日志是邏輯日志，而redo log記錄的是關于每個頁（Page）的更改的物理情況，

• 寫入的時間不同，bin log僅在事務提交前進行提交，也就是只寫磁盤一次，而在事務進行的程序中，卻不斷有redo ertry被寫入redo log中，

• 寫入的方式也不相同，redo log是回圈寫入和擦除，bin log是追加寫入，不會覆寫已經寫的檔案，

1.6、回滾日志（undo log）

提到了redo log，這里在簡單了解一下回滾日志（undo log），

回滾日志同樣也是InnoDB引擎提供的日志，顧名思義，回滾日志的作用就是對資料進行回滾，當事務對資料庫進行修改，InnoDB引擎不僅會記錄redo log，還會生成對應的undo log日志；如果事務執行失敗或呼叫了rollback，導致事務需要回滾，就可以利用undo log中的資訊將資料回滾到修改之前的樣子，

但是undo log不redo log不一樣，它屬于邏輯日志，它對SQL陳述句執行相關的資訊進行記錄，當發生回滾時，InnoDB引擎會根據undo log日志中的記錄做與之前相反的作業，比如對于每個資料插入操作（insert），回滾時會執行資料洗掉操作（delete）；對于每個資料洗掉操作（delete），回滾時會執行資料插入操作（insert）；對于每個資料更新操作（update），回滾時會執行一個相反的資料更新操作（update），把資料改回去，undo log由兩個作用，一是提供回滾，二是實作MVCC，

2、更新陳述句執行

接下來結合一條更新陳述句的執行，來進一步理解bin log和redo log這兩種重要日志，

 update t set c=c+1 where ID=2;

2.1、更新陳述句執行流程

我們來看執行器和InnoDB引擎在執行這個簡單的update陳述句時的內部流程，

1. 執行器先找引擎取ID=2這一行，ID是主鍵，引擎直接用樹搜索找到這一行，如果ID=2這一行所在的資料頁本來就在記憶體中，就直接回傳給執行器；否則，需要先從磁盤讀入記憶體，然后再回傳，

2. 執行器拿到引擎給的行資料，把這個值加上1，比如原來是N，現在就是N+1，得到新的一行資料，再呼叫引擎介面寫入這行新資料，

3. 引擎將這行新資料更新到記憶體中，同時將這個更新操作記錄到redo log里面，此時redo log處于prepare狀態，然后告知執行器執行完成了，隨時可以提交事務，

4. 執行器生成這個操作的binlog，并把binlog寫入磁盤，

5. 執行器呼叫引擎的提交事務介面，引擎把剛剛寫入的redo log改成提交（commit）狀態，更新完成，

update陳述句的執行流程圖如下：

2.2、兩階段提交

這條陳述句的執行程序中，redo log的寫入分成了兩個步驟分成了prepare和commit兩個階段進行提交，這就是所謂的兩階段提交，為什么要用兩階段提交呢？

先用通俗的說法：

比如小明去超市里買一瓶可樂：

1. 小明：老板給我來瓶可樂！透心涼心飛揚的那個，
2. 老板：機器掃一下可樂，告訴小明這瓶可樂2塊5，給錢（記錄 redo log，事務處于prepare狀態）
3. 收錢放入錢箱（記錄 binlog，事務實際是否完成的根本依據，處于待標記commit階段）
4. 然后讓小明把可樂拿走（redo log 狀態標為 commit，表示該事務邏輯倍訓），到這里，代表一筆交易結束，
5. 等算賬前再把這一天賣東西的交易資訊一起同步到資料庫，

可見，如果收錢之前（prepare階段，步驟3）交易被打斷，回過頭來處理此次交易，發現只有記了小黑板但沒有收錢，則交易失敗，刪掉小黑板上的記錄（回滾）；

如果收了錢后（commit階段 或 待commit階段，步驟4 || 5）交易被打斷，然后回過頭發現系統上有記錄（prepare）而且錢箱有本次收入（bin log），則說明本次交易有效，補充修改commit狀態，更新到庫存中，

用正式一點的語言來描述，

如果不用兩階段提交，要么就是先寫完redo log再寫binlog，或者采用反過來的順序，我們看看這兩種方式會有什么問題，

仍然用前面的update陳述句來做例子，假設當前ID=2的行，欄位c的值是0，再假設執行update陳述句程序中在寫完第一個日志后，第二個日志還沒有寫完期間發生了crash，會出現什么情況呢？

1. 先寫redo log后寫binlog，假設在redo log寫完，binlog還沒有寫完的時候，MySQL行程例外重啟，由于我們前面說過的，redo log寫完之后，系統即使崩潰，仍然能夠把資料恢復回來，所以恢復后這一行c的值是1，
   但是由于binlog沒寫完就crash了，這時候binlog里面就沒有記錄這個陳述句，因此，之后備份日志的時候，存起來的binlog里面就沒有這條陳述句，
   然后你會發現，如果需要用這個binlog來恢復臨時庫的話，由于這個陳述句的binlog丟失，這個臨時庫就會少了這一次更新，恢復出來的這一行c的值就是0，與原庫的值不同，

2. 先寫binlog后寫redo log，如果在binlog寫完之后crash，由于redo log還沒寫，崩潰恢復以后這個事務無效，所以這一行c的值是0，但是binlog里面已經記錄了“把c從0改成1”這個日志，所以，在之后用binlog來恢復的時候就多了一個事務出來，恢復出來的這一行c的值就是1，與原庫的值不同，

可以看到，如果不使用“兩階段提交”，那么資料庫的狀態就有可能和用它的日志恢復出來的庫的狀態不一致，

你可能會說，這個概率是不是很低，平時也沒有什么動不動就需要恢復臨時庫的場景呀？

其實不是的，不只是誤操作后需要用這個程序來恢復資料，當你需要擴容的時候，也就是需要再多搭建一些備庫來增加系統的讀能力的時候，現在常見的做法也是用全量備份加上應用binlog來實作的，這個“不一致”就會導致你的線上出現主從資料庫不一致的情況，

簡單說，redo log和binlog都可以用于表示事務的提交狀態，而兩階段提交就是讓這兩個狀態保持邏輯上的一致，

2.3、日志落盤

保證事務成功，日志必須落盤，這樣，資料庫crash后，就不會丟失某個事務的資料了

• innodb_flush_log_at_trx_commit 這個引數設定成 1 的時候，表示每次事務的 redo log 都直接持久化到磁盤，這樣可以保證 MySQL 例外重啟之后資料不丟失，

• sync_binlog 這個引數設定成 1 的時候，表示每次事務的 binlog 都持久化到磁盤，這樣可以保證 MySQL 例外重啟之后 binlog 不丟失，

參考：

【1】：《高性能MySQL》

【2】：極客時間 《MySQL實戰45講》

【3】：《MySQL技術內幕 InnoDB存盤引擎》

【4】：聽我講完redo log、binlog原理，面試官老臉一紅

【5】：為了讓你徹底弄懂 MySQL 事務日志，我通宵肝出了這份圖解！

【6】：MySQL中幾種常見的日志

【7】：Mysql學習筆記——重做日志與歸檔日志

【8】：淺析MySQL事務中的redo與undo