轉(zhuǎn)載自http://www.cnblogs.com/wy123/p/8365234.html
MySQL中有六種日志文件屉更，分別是
- 重做日志（redo log）
- 回滾日志（undo log）
- 二進(jìn)制日志（binlog）
- 錯(cuò)誤日志（errorlog）
- 慢查詢?nèi)罩荆╯low query log）
- 一般查詢?nèi)罩荆╣eneral log）
- 中繼日志（relay log）徙融。
??其中重做日志和回滾日志與事務(wù)操作息息相關(guān)，二進(jìn)制日志也與事務(wù)操作有一定的關(guān)系瑰谜，這三種日志欺冀，對(duì)理解MySQL中的事務(wù)操作有著重要的意義树绩。
??這里簡(jiǎn)單總結(jié)一下這三者具有一定相關(guān)性的日志。
重做日志（redo log）
作用：
確保事務(wù)的持久性脚猾。
防止在發(fā)生故障的時(shí)間點(diǎn)，尚有臟頁(yè)未寫入磁盤砚哗，在重啟mysql服務(wù)的時(shí)候龙助，根據(jù)redo log進(jìn)行重做，從而達(dá)到事務(wù)的持久性這一特性蛛芥。
內(nèi)容：
物理格式的日志提鸟，記錄的是物理數(shù)據(jù)頁(yè)面的修改的信息，其redo log是順序?qū)懭雛edo log file的物理文件中去的仅淑。
什么時(shí)候產(chǎn)生：
事務(wù)開(kāi)始之后就產(chǎn)生redo log称勋，redo log的落盤并不是隨著事務(wù)的提交才寫入的，而是在事務(wù)的執(zhí)行過(guò)程中涯竟，便開(kāi)始寫入redo log文件中赡鲜。
什么時(shí)候釋放：
當(dāng)對(duì)應(yīng)事務(wù)的臟頁(yè)寫入到磁盤之后，redo log的使命也就完成了庐船，重做日志占用的空間就可以重用（被覆蓋）银酬。
對(duì)應(yīng)的物理文件：
默認(rèn)情況下，對(duì)應(yīng)的物理文件位于數(shù)據(jù)庫(kù)的data目錄下的ib_logfile1&ib_logfile2
innodb_log_group_home_dir 指定日志文件組所在的路徑筐钟，默認(rèn)./ 揩瞪，表示在數(shù)據(jù)庫(kù)的數(shù)據(jù)目錄下。
innodb_log_files_in_group 指定重做日志文件組中文件的數(shù)量篓冲，默認(rèn)2
關(guān)于文件的大小和數(shù)量李破，由一下兩個(gè)參數(shù)配置
innodb_log_file_size 重做日志文件的大小。
innodb_mirrored_log_groups 指定了日志鏡像文件組的數(shù)量壹将，默認(rèn)1
其他：
很重要一點(diǎn)嗤攻，redo log是什么時(shí)候?qū)懕P的？前面說(shuō)了是在事務(wù)開(kāi)始之后逐步寫盤的诽俯。
之所以說(shuō)重做日志是在事務(wù)開(kāi)始之后逐步寫入重做日志文件屯曹，而不一定是事務(wù)提交才寫入重做日志緩存，
原因就是惊畏，重做日志有一個(gè)緩存區(qū)Innodb_log_buffer恶耽，Innodb_log_buffer的默認(rèn)大小為8M(這里設(shè)置的16M),Innodb存儲(chǔ)引擎先將重做日志寫入innodb_log_buffer中。
然后會(huì)通過(guò)以下三種方式將innodb日志緩沖區(qū)的日志刷新到磁盤
1颜启，Master Thread 每秒一次執(zhí)行刷新Innodb_log_buffer到重做日志文件偷俭。
2，每個(gè)事務(wù)提交時(shí)會(huì)將重做日志刷新到重做日志文件缰盏。
3涌萤，當(dāng)重做日志緩存可用空間 少于一半時(shí)淹遵，重做日志緩存被刷新到重做日志文件
由此可以看出，重做日志通過(guò)不止一種方式寫入到磁盤负溪，尤其是對(duì)于第一種方式透揣，Innodb_log_buffer到重做日志文件是Master Thread線程的定時(shí)任務(wù)。
因此重做日志的寫盤川抡，并不一定是隨著事務(wù)的提交才寫入重做日志文件的辐真，而是隨著事務(wù)的開(kāi)始，逐步開(kāi)始的崖堤。
另外引用《MySQL技術(shù)內(nèi)幕 Innodb 存儲(chǔ)引擎》（page37）上的原話：
即使某個(gè)事務(wù)還沒(méi)有提交侍咱，Innodb存儲(chǔ)引擎仍然每秒會(huì)將重做日志緩存刷新到重做日志文件。
這一點(diǎn)是必須要知道的密幔，因?yàn)檫@可以很好地解釋再大的事務(wù)的提交（commit）的時(shí)間也是很短暫的楔脯。
回滾日志（undo log）
作用：
保存了事務(wù)發(fā)生之前的數(shù)據(jù)的一個(gè)版本，可以用于回滾胯甩，同時(shí)可以提供多版本并發(fā)控制下的讀（MVCC）昧廷，也即非鎖定讀
內(nèi)容：
邏輯格式的日志，在執(zhí)行undo的時(shí)候偎箫，僅僅是將數(shù)據(jù)從邏輯上恢復(fù)至事務(wù)之前的狀態(tài)麸粮，而不是從物理頁(yè)面上操作實(shí)現(xiàn)的，這一點(diǎn)是不同于redo log的镜廉。
什么時(shí)候產(chǎn)生：
事務(wù)開(kāi)始之前弄诲，將當(dāng)前是的版本生成undo log，undo 也會(huì)產(chǎn)生 redo 來(lái)保證undo log的可靠性
什么時(shí)候釋放：
當(dāng)事務(wù)提交之后娇唯，undo log并不能立馬被刪除齐遵，
而是放入待清理的鏈表，由purge線程判斷是否由其他事務(wù)在使用undo段中表的上一個(gè)事務(wù)之前的版本信息塔插，決定是否可以清理undo log的日志空間梗摇。
對(duì)應(yīng)的物理文件：
MySQL5.6之前，undo表空間位于共享表空間的回滾段中想许，共享表空間的默認(rèn)的名稱是ibdata伶授，位于數(shù)據(jù)文件目錄中。
MySQL5.6之后流纹，undo表空間可以配置成獨(dú)立的文件糜烹，但是提前需要在配置文件中配置，完成數(shù)據(jù)庫(kù)初始化后生效且不可改變undo log文件的個(gè)數(shù)
如果初始化數(shù)據(jù)庫(kù)之前沒(méi)有進(jìn)行相關(guān)配置漱凝，那么就無(wú)法配置成獨(dú)立的表空間了疮蹦。
關(guān)于MySQL5.7之后的獨(dú)立undo 表空間配置參數(shù)如下
innodb_undo_directory = /data/undospace/ --undo獨(dú)立表空間的存放目錄
innodb_undo_logs = 128 --回滾段為128KB
innodb_undo_tablespaces = 4 --指定有4個(gè)undo log文件
如果undo使用的共享表空間，這個(gè)共享表空間中又不僅僅是存儲(chǔ)了undo的信息茸炒，共享表空間的默認(rèn)為與MySQL的數(shù)據(jù)目錄下面愕乎，其屬性由參數(shù)innodb_data_file_path配置阵苇。
其他：
undo是在事務(wù)開(kāi)始之前保存的被修改數(shù)據(jù)的一個(gè)版本，產(chǎn)生undo日志的時(shí)候感论，同樣會(huì)伴隨類似于保護(hù)事務(wù)持久化機(jī)制的redolog的產(chǎn)生绅项。
默認(rèn)情況下undo文件是保持在共享表空間的，也即ibdatafile文件中比肄，當(dāng)數(shù)據(jù)庫(kù)中發(fā)生一些大的事務(wù)性操作的時(shí)候快耿，要生成大量的undo信息，全部保存在共享表空間中的薪前。
因此共享表空間可能會(huì)變的很大润努，默認(rèn)情況下关斜，也就是undo 日志使用共享表空間的時(shí)候示括，被“撐大”的共享表空間是不會(huì)也不能自動(dòng)收縮的。
因此痢畜，mysql5.7之后的“獨(dú)立undo 表空間”的配置就顯得很有必要了垛膝。
二進(jìn)制日志（binlog）：
作用：
1，用于復(fù)制丁稀，在主從復(fù)制中吼拥，從庫(kù)利用主庫(kù)上的binlog進(jìn)行重播，實(shí)現(xiàn)主從同步线衫。
2凿可，用于數(shù)據(jù)庫(kù)的基于時(shí)間點(diǎn)的還原。
內(nèi)容：
邏輯格式的日志授账，可以簡(jiǎn)單認(rèn)為就是執(zhí)行過(guò)的事務(wù)中的sql語(yǔ)句枯跑。
但又不完全是sql語(yǔ)句這么簡(jiǎn)單，而是包括了執(zhí)行的sql語(yǔ)句（增刪改）反向的信息白热，
也就意味著delete對(duì)應(yīng)著delete本身和其反向的insert敛助；update對(duì)應(yīng)著update執(zhí)行前后的版本的信息；insert對(duì)應(yīng)著delete和insert本身的信息屋确。
在使用mysqlbinlog解析binlog之后一些都會(huì)真相大白纳击。
因此可以基于binlog做到類似于oracle的閃回功能，其實(shí)都是依賴于binlog中的日志記錄攻臀。
什么時(shí)候產(chǎn)生：
事務(wù)提交的時(shí)候焕数，一次性將事務(wù)中的sql語(yǔ)句（一個(gè)事物可能對(duì)應(yīng)多個(gè)sql語(yǔ)句）按照一定的格式記錄到binlog中。
這里與redo log很明顯的差異就是redo log并不一定是在事務(wù)提交的時(shí)候刷新到磁盤刨啸，redo log是在事務(wù)開(kāi)始之后就開(kāi)始逐步寫入磁盤百匆。
因此對(duì)于事務(wù)的提交，即便是較大的事務(wù)呜投，提交（commit）都是很快的加匈，但是在開(kāi)啟了bin_log的情況下存璃，對(duì)于較大事務(wù)的提交，可能會(huì)變得比較慢一些雕拼。
這是因?yàn)閎inlog是在事務(wù)提交的時(shí)候一次性寫入的造成的纵东，這些可以通過(guò)測(cè)試驗(yàn)證。
什么時(shí)候釋放：
對(duì)應(yīng)的物理文件：
配置文件的路徑為log_bin_basename衰絮，binlog日志文件按照指定大小，當(dāng)日志文件達(dá)到指定的最大的大小之后磷醋，進(jìn)行滾動(dòng)更新猫牡，生成新的日志文件。
對(duì)于每個(gè)binlog日志文件邓线，通過(guò)一個(gè)統(tǒng)一的index文件來(lái)組織淌友。
其他：
二進(jìn)制日志的作用之一是還原數(shù)據(jù)庫(kù)的，這與redo log很類似骇陈，很多人混淆過(guò)震庭，但是兩者有本質(zhì)的不同
1，作用不同：redo log是保證事務(wù)的持久性的你雌，是事務(wù)層面的器联，binlog作為還原的功能，是數(shù)據(jù)庫(kù)層面的（當(dāng)然也可以精確到事務(wù)層面的）婿崭，雖然都有還原的意思拨拓，但是其保護(hù)數(shù)據(jù)的層次是不一樣的。
2逛球，內(nèi)容不同：redo log是物理日志千元，是數(shù)據(jù)頁(yè)面的修改之后的物理記錄，binlog是邏輯日志颤绕，可以簡(jiǎn)單認(rèn)為記錄的就是sql語(yǔ)句
3幸海，另外，兩者日志產(chǎn)生的時(shí)間奥务，可以釋放的時(shí)間物独，在可釋放的情況下清理機(jī)制，都是完全不同的氯葬。
4挡篓，恢復(fù)數(shù)據(jù)時(shí)候的效率，基于物理日志的redo log恢復(fù)數(shù)據(jù)的效率要高于語(yǔ)句邏輯日志的binlog
??關(guān)于事務(wù)提交時(shí)，redo log和binlog的寫入順序官研，為了保證主從復(fù)制時(shí)候的主從一致（當(dāng)然也包括使用binlog進(jìn)行基于時(shí)間點(diǎn)還原的情況）秽澳，是要嚴(yán)格一致的，MySQL通過(guò)兩階段提交過(guò)程來(lái)完成事務(wù)的一致性的戏羽，也即redo log和binlog的一致性的担神，理論上是先寫redo log，再寫binlog始花，兩個(gè)日志都提交成功（刷入磁盤）妄讯，事務(wù)才算真正的完成。
參考：http://www.cnblogs.com/hustcat/p/3577584.html
總結(jié)：
??MySQL中酷宵，對(duì)于以上三種日志亥贸，每一種細(xì)化起來(lái)都可以夠?qū)懸粋€(gè)章節(jié)的，這里粗略地總結(jié)了一下三種日志的一些特點(diǎn)和作用浇垦，以幫助理解MySQL中的事物以及事物背后的原理炕置。
