1.InnoDB事務日誌（redo log 和 undo log）
爲了最大程度避免數據寫入時io瓶頸帶來的性能問題(避免頻繁使用io)，MySQL採用了這樣一種緩存機制：當query修改數據庫內數據時，InnoDB先將該數據從磁盤讀取到內存中，修改內存中的數據拷貝，並將該修改行爲持久化到磁盤上的事務日誌（日誌的更改順序是先寫內存redo
log buffer，再定期批量寫入磁盤），而不是每次都直接將修改過的數據記錄到硬盤內，等事務日誌持久化完成之後，內存中的髒數據可以慢慢刷回磁盤，稱之爲Write-Ahead
Logging。事務日誌採用的是追加寫入，順序io會帶來更好的性能優勢。
爲了避免髒數據刷回磁盤過程中，掉電或系統故障帶來的數據丟失問題，InnoDB採用事務日誌（redo log）來解決該問題
1.1 redo log
用於在實例故障恢復時，繼續那些已經commit但數據尚未完全回寫到磁盤的事務
通常會初始化2個或更多的 ib_logfile 存儲 redo log，由參數 innodb_log_files_in_group 確定個數，命名從 ib_logfile0 開始，依次寫滿 ib_logfile 並順序重用（in a circular fashion）。如果最後1個
ib_logfile 被寫滿，而第一個ib_logfile 中所有記錄的事務對數據的變更已經被持久化到磁盤中，將清空並重用之
1.2 undo
用於在實例故障恢復時，藉助undo log將尚未commit的事務，回滾到事務開始前的狀態
記錄了數據修改的前鏡像。存放於ibdata
1.3 mysql 中undo redo log在事務中起的作用
1.3.1
Undo Log 實現事務的原子性(原子性是指事務包含的所有操作要麼全部成功，要麼全部失敗回滾)
Undo Log的原理很簡單，爲了滿足事務的原子性，在操作任何數據之前，首先將數據備份到一個地方（這個存儲數據備份的地方稱爲Undo
Log）。然後進行數據的修改。如果出現了錯誤或者用戶執行了ROLLBACK語句，系統可以利用Undo Log中的備份將數據恢復到事務開始之前的狀態。
1.3.2 Redo Log 實現事務持久性(持久性是指一個事務一旦被提交了，那麼對數據庫中的數據的改變就是永久性的，即便是在數據庫系統遇到故障的情況下也不會丟失提交事務的操作)
和Undo Log相反，Redo Log記錄的是新數據的備份。在事務提交前，只要將Redo Log持久化即可，不需要將數據持久化。當系統崩潰時，雖然數據沒有持久化，但是Redo Log已經持久化。系統可以根據Redo Log的內容