MySQL 中的幾種日誌瞭解
轉載 ：https://www.cnblogs.com/myseries/p/10728533.html
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_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，Innodb 儲存引擎現將重做日誌寫入 innodb_log_buffer中。
show variables like 'innodb_log_buffer_size' ------------------------------------------------ Variable_name | Value | ------------------------------------------------ innodb_log_buffer_size | 8388608 | ------------------------------------------------
然後通過以下三種方式將 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 的日誌空間
對應的物理檔案：
MySQL 5.6 之前， undo 表空間位於共享表空間的回滾段中， 共享表空間的預設的名稱是 ibdata, 位於資料檔案目錄中。
MySQL5.6 之後，undo 表空間可以配置成獨立的檔案，但是提前需要在配置檔案中配置，完成資料庫初始化後生效且不可改變 undo log 檔案的個數
如果初始化資料庫之前沒有進行相關的配置，那麼就無法配置成獨立的表空間了。
關於MySQL5.7 之後獨立 undo 表空間配置的引數如下：
innodb_undo_directory = /data/undospace/ -- 獨立表空間的存放目錄
innodb_undo_logs = 128 -- 回滾段為128KB
innodb_undo_tablespaces = 4 -- 指定有 4 個 undo log 檔案
如果 undo 使用的共享表空間， 這個共享表空間中不僅僅是儲存了 undo 的資訊， 共享表空間的預設為 與 MySQL 的資料目錄下面，其屬性由引數 innodb_data_file_path 配置。
show variables like '%innodb_data_file_path%'; -------------------------------------------------------- Variable_name | Value -------------------------------------------------------- innodb_data_file_path | ibdata1:12M:autoextend --------------------------------------------------------
其他：
undo 是在事務開始之前儲存的被修改資料的一個版本，產生 undo 日誌的時候，同時會伴隨類似於保護事務持久化機制的 redolog 產生。
預設情況下，undo檔案是儲存在共享表空間的，也即 ibdatafile 檔案中， 當資料庫中發生一些大的事務性操作的時候，要生成大量的undo 資訊， 全部儲存在共享表空間中的。
因此共享表空間可能會變得很大，預設情況下，也就是 undo 日誌使用共享表空間的時候，被“撐大” 的共享表空間是不會也不能自動收縮的。
因此， Mysql 5.7 之後的 “獨立 undo 表空間” 的配置就顯得很有必要了。
三、 二進位制日誌 (binlog)
作用：
用於複製，在主從復置中，從庫利用主庫上的 binlog 進行重播， 實現主從同步。
用於資料庫的基於時間點的還原。
內容：
邏輯格式的日誌，也可以簡單認為就是執行過的事務中的sql語句。
但又不完全是sql 語句這麼簡單， 而是包括了執行的sql 語句(增刪改) 反向的資訊， 也就意味著 delete 對應著 delete 本身和其反向的 insert; update 對應著 update 執行前後的版本資訊； insert對應著delete 和 insert 本身的資訊。
在使用 mysql binlog 解析 binlog 之後一切都會真相大白。
因此可以基於 binlog 做到類似於 oracle 的閃回宮呢功能，其實都是依賴於 binlog 中的日誌記錄。
什麼時候產生：
事務提交的時候，一次性將事務中的sql 語句(一個事務可能對應多個 sql 語句) 按照一定的格式記錄到 binlog 中。
這裡與 redo log 很明顯的差異就是 redo log 並不一定是在事務提交的時候重新整理到磁碟，redo log 是在事務開始之後就開始逐步寫入磁碟。
因此對於事務的提交， 即便是較大的事務， 提交(commit) 都是很快的， 但是在開啟了 bin_log 的情況下， 對於較大的事務的提交，可能會變得比較慢一些。
這是因為 binlog 是在事務提交的時候一次性寫入造成的，這些可以通過測試驗證。
什麼時候釋放：
binlog 的預設 是保持時間由引數 expire_log_days 配置， 也就是說對於非活動的日誌檔案，在生成時間超過 expire_logs_days 配置的天數之後，會被自動刪除。
show variables like '%expire_logs_days%'; ---------------------------------------------- Variable_name | Value ---------------------------------------------- expire_logs_days | 0 ----------------------------------------------
對應的物理檔案：
配置檔案的路徑為 log_bin_basename, binlog 日誌檔案按照指定大小，當日志文件達到指定的最大的大小之後， 進行滾動更新， 生成新的日誌檔案
對於每個 binlog日誌檔案， 通過一個統一的 index 檔案來組織。
show variables like '%log_bin_basename%'; --------------------------------------------------- Variable_name | Value --------------------------------------------------- log_bin_basename | /usr/local/mysql/binlog/binlog ---------------------------------------------------
其他：
二進位制日誌的作用之一是還原資料庫的， 這與 redo log 很類似， 很多人混淆過， 但是兩者有著本質的不同。
作用不同： redo log 是保證事務的永續性的， 是事務層面的， binlog 作為還原的功能，是資料庫層面的(當然也可以精確到事務層面的), 雖然都有還原的意思， 但是其保護的資料的層次是不一樣的
內容不同：redo log 是物理日誌， 是資料頁面的修改之後的物理記錄， binlog 是邏輯日誌， 可以簡單認為記錄的就是 sql語句。
另外，兩者 日誌產生的時間， 可以釋放的時間， 在可釋放的情況下清理機制，都是完全不同的。
恢復資料的時候的效率，基於物理日誌的 redo log 恢復資料的效率要高於語句邏輯日誌的 bin log。
關於事務提交時， redo log 和 binlog 的寫入順序，為了保證主從複製的時候主從一致，(當然也包括使用 binlog 進行基於時間點還原的情況), 要是在嚴格一致的， Mysql 通過兩階段提交過程來完成事務的一致性的， 也即 redo log 和 binlog 的一致性的，理論上是先寫 redo log， 在寫 bin log， 兩個日誌都提交成功(刷入磁碟), 事務才算真正的完成。
四、錯誤日誌 (errorlog)
錯誤日誌記錄著mysqld啟動和停止,以及伺服器在執行過程中發生的錯誤的相關資訊。在預設情況下，系統記錄錯誤日誌的功能是關閉的，錯誤資訊被輸出到標準錯誤輸出。
指定日誌路徑兩種方法:
編輯my.cnf 寫入 log-error=[path]
通過命令引數錯誤日誌 mysqld_safe –user=mysql –log-error=[path] &
顯示錯誤日誌的命令（如下圖所示）
show variables like '%err%';
五、普通查詢日誌 (general query log)
記錄了伺服器接收到的每一個查詢或是命令，無論這些查詢或是命令是否正確甚至是否包含語法錯誤，general log 都會將其記錄下來 ，記錄的格式為 {Time ，Id ，Command，Argument }。也正因為mysql伺服器需要不斷地記錄日誌，開啟General log會產生不小的系統開銷。 因此，Mysql預設是把General log關閉的。
檢視日誌的存放方式：show variables like ‘log_output’;
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;
set global general_log=on; show variables like 'general_log';
六、慢查詢日誌 (slow query 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、開啟慢日誌
set global slow_query_log=1; show variables like '%slow_query_log%';