MySQL中有以下日志文件，分別是：

1：重做日志（redo log）
2：回滾日志（undo log）
3：二進制日志（binlog）
4：錯誤日志（errorlog）
5：慢查詢日志（slow query log）
6：一般查詢日志（general log）
7：中繼日志（relay log）

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

一、重做日志（redo log）

作用：
　　確保事務的持久性。redo日志記錄事務執行后的狀態，用來恢復未寫入data file的已成功事務更新的數據。防止在發生故障的時間點，尚有臟頁未寫入磁盤，在重啟mysql服務的時候，根據redo log進行重做，從而達到事務的持久性這一特性。

內容：
　　物理格式的日志，記錄的是物理數據頁面的修改的信息，其redo log是順序寫入redo log file的物理文件中去的。

什么時候產生：
　　事務開始之后就產生redo log，redo log的落盤并不是隨著事務的提交才寫入的，而是在事務的執行過程中，便開始寫入redo log文件中。

什么時候釋放：
　　當對應事務的臟頁寫入到磁盤之后，redo log的使命也就完成了，重做日志占用的空間就可以重用（被覆蓋）。

對應的物理文件：
　　默認情況下，對應的物理文件位于數據庫的data目錄下的ib_logfile1ib_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日志緩沖區的日志刷新到磁盤

Master Thread 每秒一次執行刷新Innodb_log_buffer到重做日志文件。

每個事務提交時會將重做日志刷新到重做日志文件。

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

由此可以看出，重做日志通過不止一種方式寫入到磁盤，尤其是對于第一種方式，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）

作用：
　　用于復制，在主從復制中，從庫利用主庫上的binlog進行重播，實現主從同步。
　　用于數據庫的基于時間點的還原。

內容：
　　邏輯格式的日志，可以簡單認為就是執行過的事務中的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很類似，很多人混淆過，但是兩者有本質的不同
　　作用不同：redo log是保證事務的持久性的，是事務層面的，binlog作為還原的功能，是數據庫層面的（當然也可以精確到事務層面的），雖然都有還原的意思，但是其保護數據的層次是不一樣的。
　　內容不同：redo log是物理日志，是數據頁面的修改之后的物理記錄，binlog是邏輯日志，可以簡單認為記錄的就是sql語句
　　另外，兩者日志產生的時間，可以釋放的時間，在可釋放的情況下清理機制，都是完全不同的。
　　恢復數據時候的效率，基于物理日志的redo log恢復數據的效率要高于語句邏輯日志的binlog
　　關于事務提交時，redo log和binlog的寫入順序，為了保證主從復制時候的主從一致（當然也包括使用binlog進行基于時間點還原的情況），是要嚴格一致的，MySQL通過兩階段提交過程來完成事務的一致性的，也即redo log和binlog的一致性的，理論上是先寫redo log，再寫binlog，兩個日志都提交成功（刷入磁盤），事務才算真正的完成。

四、錯誤日志

錯誤日志記錄著mysqld啟動和停止,以及服務器在運行過程中發生的錯誤的相關信息。在默認情況下，系統記錄錯誤日志的功能是關閉的，錯誤信息被輸出到標準錯誤輸出。
　　指定日志路徑兩種方法:
　　1）編輯my.cnf 寫入 log-error=[path]
　　2）通過命令參數錯誤日志 mysqld_safe –user=mysql –log-error=[path]

顯示錯誤日志的命令（如下圖所示）

五、普通查詢日志 general query log

記錄了服務器接收到的每一個查詢或是命令，無論這些查詢或是命令是否正確甚至是否包含語法錯誤，general log 都會將其記錄下來 ，記錄的格式為 {Time ，Id ，Command，Argument }。也正因為mysql服務器需要不斷地記錄日志，開啟General log會產生不小的系統開銷。 因此，Mysql默認是把General log關閉的。

查看日志的存放方式：show variables like ‘log_output';

如果設置mysql> set global log_output='table' 的話，則日志結果會記錄到名為gengera_log的表中，這表的默認引擎都是CSV
如果設置表數據到文件set global log_output=file;
設置general log的日志文件路徑：
set global general_log_file='/tmp/general.log';
開啟general log： set global general_log=on;
關閉general log： set global general_log=off;

然后在用：show global variables like ‘general_log'

六、慢查詢日志

慢日志記錄執行時間過長和沒有使用索引的查詢語句，報錯select、update、delete以及insert語句，慢日志只會記錄執行成功的語句。

1. 查看慢查詢時間：

show variables like “long_query_time”;默認10s

2. 查看慢查詢配置情況：

show status like “%slow_queries%”;

3. 查看慢查詢日志路徑：

show variables like “%slow%”;

4. 開啟慢日志

查看已經開啟：

到此這篇關于mysql中的7種日志小結的文章就介紹到這了,更多相關mysql 日志內容請搜索腳本之家以前的文章或繼續瀏覽下面的相關文章希望大家以后多多支持腳本之家！