MySQL中有六種日志檔案，
分别是：重做日志（redo log）、復原日志（undo log）、二進制日志（binlog）、錯誤日志（errorlog）、慢查詢日志（slow query log）、一般查詢日志（general log），中繼日志（relay log）。
其中重做日志和復原日志與事務操作息息相關，二進制日志也與事務操作有一定的關系，這三種日志，對了解MySQL中的事務操作有着重要的意義。
這裡簡單總結一下這三者具有一定相關性的日志。
重做日志（redo log）
作用：
確定事務的持久性。
防止在發生故障的時間點，尚有髒頁未寫入磁盤，在重新開機mysql服務的時候，根據redo log進行重做，進而達到事務的持久性這一特性。
内容：
實體格式的日志，記錄的是實體資料頁面的修改的資訊，其redo log是順序寫入redo log file的實體檔案中去的。
什麼時候産生：
事務開始之後就産生redo log，redo log的落盤并不是随着事務的送出才寫入的，而是在事務的執行過程中，便開始寫入redo log檔案中。
什麼時候釋放：
當對應事務的髒頁寫入到磁盤之後，redo log的使命也就完成了，重做日志占用的空間就可以重用（被覆寫）。
對應的實體檔案：
預設情況下，對應的實體檔案位于資料庫的data目錄下的ib_logfile1&ib_logfile2
innodb_log_group_home_dir 指定日志檔案組所在的路徑，預設./ ，表示在資料庫的資料目錄下。
innodb_log_files_in_group 指定重做日志檔案組中檔案的數量，預設2
關于檔案的大小和數量，由一下兩個參數配置
innodb_log_file_size 重做日志檔案的大小。
innodb_mirrored_log_groups 指定了日志鏡像檔案組的數量，預設1
其他：
很重要一點，redo log是什麼時候寫盤的？前面說了是在事物開始之後逐漸寫盤的。
之是以說重做日志是在事務開始之後逐漸寫入重做日志檔案，而不一定是事務送出才寫入重做日志緩存，
原因就是，重做日志有一個緩存區Innodb_log_buffer，Innodb_log_buffer的預設大小為8M(這裡設定的16M),Innodb存儲引擎先将重做日志寫入innodb_log_buffer中。
然後會通過以下三種方式将innodb日志緩沖區的日志重新整理到磁盤
1，Master Thread 每秒一次執行重新整理Innodb_log_buffer到重做日志檔案。
2，每個事務送出時會将重做日志重新整理到重做日志檔案。
3，當重做日志緩存可用空間 少于一半時，重做日志緩存被重新整理到重做日志檔案
由此可以看出，重做日志通過不止一種方式寫入到磁盤，尤其是對于第一種方式，Innodb_log_buffer到重做日志檔案是Master Thread線程的定時任務。
是以重做日志的寫盤，并不一定是随着事務的送出才寫入重做日志檔案的，而是随着事務的開始，逐漸開始的。
另外引用《MySQL技術内幕 Innodb 存儲引擎》（page37）上的原話：
即使某個事務還沒有送出，Innodb存儲引擎仍然每秒會将重做日志緩存重新整理到重做日志檔案。
這一點是必須要知道的，因為這可以很好地解釋再大的事務的送出（commit）的時間也是很短暫的。
復原日志（undo log）
作用：
儲存了事務發生之前的資料的一個版本，可以用于復原，同時可以提供多版本并發控制下的讀（MVCC），也即非鎖定讀
内容：
邏輯格式的日志，在執行undo的時候，僅僅是将資料從邏輯上恢複至事務之前的狀态，而不是從實體頁面上操作實作的，這一點是不同于redo log的。
什麼時候産生：
事務開始之前，将目前是的版本生成undo log，undo 也會産生 redo 來保證undo log的可靠性
什麼時候釋放：
當事務送出之後，undo log并不能立馬被删除，
而是放入待清理的連結清單，由purge線程判斷是否由其他事務在使用undo段中表的上一個事務之前的版本資訊，決定是否可以清理undo log的日志空間。
對應的實體檔案：
MySQL5.6之前，undo表空間位于共享表空間的復原段中，共享表空間的預設的名稱是ibdata，位于資料檔案目錄中。
MySQL5.6之後，undo表空間可以配置成獨立的檔案，但是提前需要在配置檔案中配置，完成資料庫初始化後生效且不可改變undo log檔案的個數
如果初始化資料庫之前沒有進行相關配置，那麼就無法配置成獨立的表空間了。
關于MySQL5.7之後的獨立undo 表空間配置參數如下
innodb_undo_directory = /data/undospace/ --undo獨立表空間的存放目錄
innodb_undo_logs = 128 --復原段為128KB
innodb_undo_tablespaces = 4 --指定有4個undo log檔案
如果undo使用的共享表空間，這個共享表空間中又不僅僅是存儲了undo的資訊，共享表空間的預設為與MySQL的資料目錄下面，其屬性由參數innodb_data_file_path配置。
其他：
undo是在事務開始之前儲存的被修改資料的一個版本，産生undo日志的時候，同樣會伴随類似于保護事務持久化機制的redolog的産生。
預設情況下undo檔案是保持在共享表空間的，也即ibdatafile檔案中，當資料庫中發生一些大的事務性操作的時候，要生成大量的undo資訊，全部儲存在共享表空間中的。
是以共享表空間可能會變的很大，預設情況下，也就是undo 日志使用共享表空間的時候，被“撐大”的共享表空間是不會也不能自動收縮的。
是以，mysql5.7之後的“獨立undo 表空間”的配置就顯得很有必要了。
二進制日志（binlog）：
作用：
1，用于複制，在主從複制中，從庫利用主庫上的binlog進行重播，實作主從同步。
2，用于資料庫的基于時間點的還原。
内容：
邏輯格式的日志，可以簡單認為就是執行過的事務中的sql語句。
但又不完全是sql語句這麼簡單，而是包括了執行的sql語句（增删改）反向的資訊，
也就意味着delete對應着delete本身和其反向的insert；update對應着update執行前後的版本的資訊；insert對應着delete和insert本身的資訊。
在使用mysqlbinlog解析binlog之後一些都會真相大白。
是以可以基于binlog做到類似于oracle的閃回功能，其實都是依賴于binlog中的日志記錄。
什麼時候産生：
事務送出的時候，一次性将事務中的sql語句（一個事物可能對應多個sql語句）按照一定的格式記錄到binlog中。
這裡與redo log很明顯的差異就是redo log并不一定是在事務送出的時候重新整理到磁盤，redo log是在事務開始之後就開始逐漸寫入磁盤。
是以對于事務的送出，即便是較大的事務，送出（commit）都是很快的，但是在開啟了bin_log的情況下，對于較大事務的送出，可能會變得比較慢一些。
這是因為binlog是在事務送出的時候一次性寫入的造成的，這些可以通過測試驗證。
什麼時候釋放：
binlog的預設是保持時間由參數expire_logs_days配置，也就是說對于非活動的日志檔案，在生成時間超過expire_logs_days配置的天數之後，會被自動删除。
對應的實體檔案：
配置檔案的路徑為log_bin_basename，binlog日志檔案按照指定大小，當日志檔案達到指定的最大的大小之後，進行滾動更新，生成新的日志檔案。
對于每個binlog日志檔案，通過一個統一的index檔案來組織。
其他：
二進制日志的作用之一是還原資料庫的，這與redo log很類似，很多人混淆過，但是兩者有本質的不同
1，作用不同：redo log是保證事務的持久性的，是事務層面的，binlog作為還原的功能，是資料庫層面的（當然也可以精确到事務層面的），雖然都有還原的意思，但是其保護資料的層次是不一樣的。
2，内容不同：redo log是實體日志，是資料頁面的修改之後的實體記錄，binlog是邏輯日志，可以簡單認為記錄的就是sql語句
3，另外，兩者日志産生的時間，可以釋放的時間，在可釋放的情況下清理機制，都是完全不同的。
4，恢複資料時候的效率，基于實體日志的redo log恢複資料的效率要高于語句邏輯日志的binlog
關于事務送出時，redo log和binlog的寫入順序，為了保證主從複制時候的主從一緻（當然也包括使用binlog進行基于時間點還原的情況），是要嚴格一緻的，
MySQL通過兩階段送出過程來完成事務的一緻性的，也即redo log和binlog的一緻性的，理論上是先寫redo log，再寫binlog，兩個日志都送出成功（刷入磁盤），事務才算真正的完成。
參考：http://www.cnblogs.com/hustcat/p/3577584.html
總結：
MySQL中，對于以上三種日志，每一種細化起來都可以夠寫一個章節的，這裡粗略地總結了一下三種日志的一些特點和作用，以幫助了解MySQL中的事物以及事物背後的原理。
MySQL中有六種日志檔案，
分别是：重做日志（redo log）、復原日志（undo log）、二進制日志（binlog）、錯誤日志（errorlog）、慢查詢日志（slow query log）、一般查詢日志（general log），中繼日志（relay log）。
其中重做日志和復原日志與事務操作息息相關，二進制日志也與事務操作有一定的關系，這三種日志，對了解MySQL中的事務操作有着重要的意義。
這裡簡單總結一下這三者具有一定相關性的日志。
重做日志（redo log）