MySQL中有六種日志文件，分別是

重做日志(redo log)

回滾日志(undo log)

二進制日志(binlog)

錯誤日志(errorlog)

慢查詢?nèi)罩?slow query log)

一般查詢?nèi)罩?general log)

中繼日志(relay log)。

其中重做日志和回滾日志與事務(wù)操作息息相關(guān)，二進制日志也與事務(wù)操作有一定的關(guān)系，這三種日志，對理解MySQL中的事務(wù)操作有著重要的意義。

這里簡單總結(jié)一下這三者具有一定相關(guān)性的日志。

重做日志(redo log)

作用：

確保事務(wù)的持久性。

防止在發(fā)生故障的時間點，尚有臟頁未寫入磁盤，在重啟mysql服務(wù)的時候，根據(jù)redo log進行重做，從而達到事務(wù)的持久性這一特性。

內(nèi)容：

物理格式的日志，記錄的是物理數(shù)據(jù)頁面的修改的信息，其redo log是順序?qū)懭雛edo log file的物理文件中去的。

什么時候產(chǎn)生：

事務(wù)開始之后就產(chǎn)生redo log，redo log的落盤并不是隨著事務(wù)的提交才寫入的，而是在事務(wù)的執(zhí)行過程中，便開始寫入redo log文件中。

什么時候釋放：

當對應(yīng)事務(wù)的臟頁寫入到磁盤之后，redo log的使命也就完成了，重做日志占用的空間就可以重用(被覆蓋)。

對應(yīng)的物理文件：

默認情況下，對應(yīng)的物理文件位于數(shù)據(jù)庫的data目錄下的ib_logfile1&ib_logfile2

innodb_log_group_home_dir 指定日志文件組所在的路徑，默認./ ，表示在數(shù)據(jù)庫的數(shù)據(jù)目錄下。

innodb_log_files_in_group 指定重做日志文件組中文件的數(shù)量，默認2

關(guān)于文件的大小和數(shù)量，由一下兩個參數(shù)配置

innodb_log_file_size 重做日志文件的大小。

innodb_mirrored_log_groups 指定了日志鏡像文件組的數(shù)量，默認1

其他：

很重要一點，redo log是什么時候?qū)懕P的？前面說了是在事務(wù)開始之后逐步寫盤的。

之所以說重做日志是在事務(wù)開始之后逐步寫入重做日志文件，而不一定是事務(wù)提交才寫入重做日志緩存，

原因就是，重做日志有一個緩存區(qū)Innodb_log_buffer，Innodb_log_buffer的默認大小為8M(這里設(shè)置的16M),Innodb存儲引擎先將重做日志寫入innodb_log_buffer中。

然后會通過以下三種方式將innodb日志緩沖區(qū)的日志刷新到磁盤

1，Master Thread 每秒一次執(zhí)行刷新Innodb_log_buffer到重做日志文件。

2，每個事務(wù)提交時會將重做日志刷新到重做日志文件。

3，當重做日志緩存可用空間 少于一半時，重做日志緩存被刷新到重做日志文件

由此可以看出，重做日志通過不止一種方式寫入到磁盤，尤其是對于第一種方式，Innodb_log_buffer到重做日志文件是Master Thread線程的定時任務(wù)。

因此重做日志的寫盤，并不一定是隨著事務(wù)的提交才寫入重做日志文件的，而是隨著事務(wù)的開始，逐步開始的。

另外引用《MySQL技術(shù)內(nèi)幕 Innodb 存儲引擎》(page37)上的原話：

即使某個事務(wù)還沒有提交，Innodb存儲引擎仍然每秒會將重做日志緩存刷新到重做日志文件。

這一點是必須要知道的，因為這可以很好地解釋再大的事務(wù)的提交(commit)的時間也是很短暫的。

回滾日志(undo log)

作用：

保存了事務(wù)發(fā)生之前的數(shù)據(jù)的一個版本，可以用于回滾，同時可以提供多版本并發(fā)控制下的讀(MVCC)，也即非鎖定讀

內(nèi)容：

邏輯格式的日志，在執(zhí)行undo的時候，僅僅是將數(shù)據(jù)從邏輯上恢復(fù)至事務(wù)之前的狀態(tài)，而不是從物理頁面上操作實現(xiàn)的，這一點是不同于redo log的。

什么時候產(chǎn)生：

事務(wù)開始之前，將當前是的版本生成undo log，undo 也會產(chǎn)生 redo 來保證undo log的可靠性

什么時候釋放：

當事務(wù)提交之后，undo log并不能立馬被刪除，

而是放入待清理的鏈表，由purge線程判斷是否由其他事務(wù)在使用undo段中表的上一個事務(wù)之前的版本信息，決定是否可以清理undo log的日志空間。

對應(yīng)的物理文件：

MySQL5.6之前，undo表空間位于共享表空間的回滾段中，共享表空間的默認的名稱是ibdata，位于數(shù)據(jù)文件目錄中。

MySQL5.6之后，undo表空間可以配置成獨立的文件，但是提前需要在配置文件中配置，完成數(shù)據(jù)庫初始化后生效且不可改變undo log文件的個數(shù)

如果初始化數(shù)據(jù)庫之前沒有進行相關(guān)配置，那么就無法配置成獨立的表空間了。

關(guān)于MySQL5.7之后的獨立undo 表空間配置參數(shù)如下

innodb_undo_directory = /data/undospace/ --undo獨立表空間的存放目錄

innodb_undo_logs = 128 --回滾段為128KB

innodb_undo_tablespaces = 4 --指定有4個undo log文件

如果undo使用的共享表空間，這個共享表空間中又不僅僅是存儲了undo的信息，共享表空間的默認為與MySQL的數(shù)據(jù)目錄下面，其屬性由參數(shù)innodb_data_file_path配置。

其他：

undo是在事務(wù)開始之前保存的被修改數(shù)據(jù)的一個版本，產(chǎn)生undo日志的時候，同樣會伴隨類似于保護事務(wù)持久化機制的redolog的產(chǎn)生。

默認情況下undo文件是保持在共享表空間的，也即ibdatafile文件中，當數(shù)據(jù)庫中發(fā)生一些大的事務(wù)性操作的時候，要生成大量的undo信息，全部保存在共享表空間中的。

因此共享表空間可能會變的很大，默認情況下，也就是undo 日志使用共享表空間的時候，被“撐大”的共享表空間是不會也不能自動收縮的。

因此，mysql5.7之后的“獨立undo 表空間”的配置就顯得很有必要了。

二進制日志(binlog)：

作用：

1，用于復(fù)制，在主從復(fù)制中，從庫利用主庫上的binlog進行重播，實現(xiàn)主從同步。

2，用于數(shù)據(jù)庫的基于時間點的還原。

內(nèi)容：

邏輯格式的日志，可以簡單認為就是執(zhí)行過的事務(wù)中的sql語句。

但又不完全是sql語句這么簡單，而是包括了執(zhí)行的sql語句(增刪改)反向的信息，

也就意味著delete對應(yīng)著delete本身和其反向的insert；update對應(yīng)著update執(zhí)行前后的版本的信息；insert對應(yīng)著delete和insert本身的信息。

在使用mysqlbinlog解析binlog之后一些都會真相大白。

因此可以基于binlog做到類似于oracle的閃回功能，其實都是依賴于binlog中的日志記錄。

什么時候產(chǎn)生：

事務(wù)提交的時候，一次性將事務(wù)中的sql語句(一個事物可能對應(yīng)多個sql語句)按照一定的格式記錄到binlog中。

這里與redo log很明顯的差異就是redo log并不一定是在事務(wù)提交的時候刷新到磁盤，redo log是在事務(wù)開始之后就開始逐步寫入磁盤。

因此對于事務(wù)的提交，即便是較大的事務(wù)，提交(commit)都是很快的，但是在開啟了bin_log的情況下，對于較大事務(wù)的提交，可能會變得比較慢一些。

這是因為binlog是在事務(wù)提交的時候一次性寫入的造成的，這些可以通過測試驗證。

什么時候釋放：

binlog的默認是保持時間由參數(shù)expire_logs_days配置，也就是說對于非活動的日志文件，在生成時間超過expire_logs_days配置的天數(shù)之后，會被自動刪除。

對應(yīng)的物理文件：

配置文件的路徑為log_bin_basename，binlog日志文件按照指定大小，當日志文件達到指定的最大的大小之后，進行滾動更新，生成新的日志文件。

對于每個binlog日志文件，通過一個統(tǒng)一的index文件來組織。

其他：

二進制日志的作用之一是還原數(shù)據(jù)庫的，這與redo log很類似，很多人混淆過，但是兩者有本質(zhì)的不同

1，作用不同：redo log是保證事務(wù)的持久性的，是事務(wù)層面的，binlog作為還原的功能，是數(shù)據(jù)庫層面的(當然也可以精確到事務(wù)層面的)，雖然都有還原的意思，但是其保護數(shù)據(jù)的層次是不一樣的。

2，內(nèi)容不同：redo log是物理日志，是數(shù)據(jù)頁面的修改之后的物理記錄，binlog是邏輯日志，可以簡單認為記錄的就是sql語句

3，另外，兩者日志產(chǎn)生的時間，可以釋放的時間，在可釋放的情況下清理機制，都是完全不同的。

4，恢復(fù)數(shù)據(jù)時候的效率，基于物理日志的redo log恢復(fù)數(shù)據(jù)的效率要高于語句邏輯日志的binlog

關(guān)于事務(wù)提交時，redo log和binlog的寫入順序，為了保證主從復(fù)制時候的主從一致(當然也包括使用binlog進行基于時間點還原的情況)，是要嚴格一致的，MySQL通過兩階段提交過程來完成事務(wù)的一致性的，也即redo log和binlog的一致性的，理論上是先寫redo log，再寫binlog，兩個日志都提交成功(刷入磁盤)，事務(wù)才算真正的完成。

參考：http://www.cnblogs.com/hustcat/p/3577584.html

總結(jié)：

MySQL中，對于以上三種日志，每一種細化起來都可以夠?qū)懸粋€章節(jié)的，這里粗略地總結(jié)了一下三種日志的一些特點和作用，以幫助理解MySQL中的事物以及事物背后的原理。

總結(jié)

以上是生活随笔為你收集整理的mysql重做日志与binlog日志区别_MySQL中的重做日志（redo log），回滚日志（undo log），以及二进制日志（binlog）的简单总结...的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。