在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語句時的內部流程。
-
執行器先找引擎取ID=2這一行。ID是主鍵，引擎直接用樹搜尋找到這一行。如果ID=2這一行所在的資料頁本來就在記憶體中，就直接返回給執行器；否則，需要先從磁碟讀入記憶體，然後再返回。
-
執行器拿到引擎給的行資料，把這個值加上1，比如原來是N，現在就是N+1，得到新的一行資料，再呼叫引擎介面寫入這行新資料。
-
引擎將這行新資料更新到記憶體中，同時將這個更新操作記錄到redo log裡面，此時redo log處於prepare狀態。然後告知執行器執行完成了，隨時可以提交事務。
-
執行器生成這個操作的binlog，並把binlog寫入磁碟。
-
執行器呼叫引擎的提交事務介面，引擎把剛剛寫入的redo log改成提交（commit）狀態，更新完成。
update語句的執行流程圖如下：
2.2、兩階段提交
這條語句的執行過程中，redo log的寫入分成了兩個步驟分成了prepare和commit兩個階段進行提交，這就是所謂的兩階段提交。為什麼要用兩階段提交呢？
先用通俗的說法：
比如小明去超市裡買一瓶可樂：
- 小明：老闆給我來瓶可樂！透心涼心飛揚的那個。
- 老闆：機器掃一下可樂，告訴小明這瓶可樂2塊5，給錢（記錄 redo log，事務處於prepare狀態）
- 收錢放入錢箱（記錄 binlog，事務實際是否完成的根本依據，處於待標記commit階段）
- 然後讓小明把可樂拿走（redo log 狀態標為 commit，表示該事務邏輯閉環）。到這裡，代表一筆交易結束。
- 等算賬前再把這一天賣東西的交易資訊一起同步到資料庫。
可見，如果收錢之前（prepare階段，步驟3）交易被打斷，回過頭來處理此次交易，發現只有記了小黑板但沒有收錢，則交易失敗，刪掉小黑板上的記錄（回滾）；
如果收了錢後（commit階段 或 待commit階段，步驟4 || 5）交易被打斷，然後回過頭發現系統上有記錄（prepare）而且錢箱有本次收入（bin log），則說明本次交易有效，補充修改commit狀態，更新到庫存中。
用正式一點的語言來描述。
如果不用兩階段提交，要麼就是先寫完redo log再寫binlog，或者採用反過來的順序。我們看看這兩種方式會有什麼問題。
仍然用前面的update語句來做例子。假設當前ID=2的行，欄位c的值是0，再假設執行update語句過程中在寫完第一個日誌後，第二個日誌還沒有寫完期間發生了crash，會出現什麼情況呢？
- 先寫redo log後寫binlog。假設在redo log寫完，binlog還沒有寫完的時候，MySQL程式異常重啟。由於我們前面說過的，redo log寫完之後，系統即使崩潰，仍然能夠把資料恢復回來，所以恢復後這一行c的值是1。
但是由於binlog沒寫完就crash了，這時候binlog裡面就沒有記錄這個語句。因此，之後備份日誌的時候，存起來的binlog裡面就沒有這條語句。
然後你會發現，如果需要用這個binlog來恢復臨時庫的話，由於這個語句的binlog丟失，這個臨時庫就會少了這一次更新，恢復出來的這一行c的值就是0，與原庫的值不同。
- 先寫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中幾種常見的日誌