共計 4749 個字符，預計需要花費 12 分鐘才能閱讀完成。

這篇文章主要講解了“有哪些關于 MySQL 日志”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著丸趣 TV 小編的思路慢慢深入，一起來研究和學習“有哪些關于 MySQL 日志”吧！

MySQL 日志

說起 MySQL 的日志，有三種類型的日志對于 MySQL 來說是至關重要的，這三種日志分別為：Binlog、Undo Log 和 Redo Log。

由于 Binlog 和 UndoLog 有類似的地方，所以，我們按照如下順序依次介紹 MySQL 中的三大日志原理：Undo Log mdash; mdash; Redo Log   mdash; mdash; Binlog。

Undo Log 日志

什么是 Undo Log

顧名思義，Undo Log 的字面意思就是撤銷操作的日志，指的是使 MySQL 中的數據回到某個狀態。

在 MySQL 數據庫中，事務開始之前，MySQL 會將待修改的記錄保存到 Undo Log 中，如果數據庫崩潰或者事務需要回滾時，MySQL 可以通過利用 Undo  Log 日志，將數據庫中的數據回滾到之前的狀態。

MySQL 新增、修改和刪除數據時，在事務開始前，就會將信息寫入 Undo Log 中。事務提交時，并不會立刻刪除 Undo Log， InnoDB 存儲引擎會將事務對應的 Undo Log 放入待刪除列表中，之后會通過后臺的 purge  thread 對待刪除的列表進行刪除處理。這里，值得注意的是：Undo Log 是一種 邏輯日志，  記錄的是一個變化過程。比如，MySQL 執行一個 delete 操作，Undo Log 就會記錄一個 insert 操作;MySQL 執行一個 insert 操作，Undo  Log 就會記錄一個 delete 操作;MySQL 執行一個 update 操作，Undo Log 就會記錄一個相反的 update 操作。

Undo Log 以段的方式來管理和記錄日志信息，在 InnoDB 存儲引擎的數據文件中，包含了一種叫做 rollback  segment 的回滾段，其內部包含了 1024 個 undo log senment。

Undo Log 作用

Undo Log 對于 MySQL 實現事務來說，起著至關重要的作用，它實現了事務的原子性和多版本并發控制，也就是我們經常說的 MVCC。

實現事務的原子性

Undo  Log 能夠實現 MySQL 事務的原子性，在事務的處理過程中，如果 MySQL 出現了錯誤或者用戶手動執行了事務的回滾操作(執行了 rollback 操作)，MySQL 可以利用 Undo  Log 日志將數據庫中的數據恢復到之前的狀態。

實現 MVCC 機制

Undo Log 在 MySQL 的 InnoDB 存儲引擎中實現了多版本并發控制 (MVCC) 機制。事務未提交前，Undo  Log 保存了未提交之前的版本數據，Undo Log 中的數據可以作為舊版本數據的副本或者快照以便其他并發事務進行讀取操作。

事務 A 手動開啟事務后，對 goods 數據表中 id 為 1 的數據進行更新操作，首先會把更新命中的數據寫入到 Undo  Buffer 中。在事務 A 未提交之前，此時，事務 B 手動開啟事務，對 goods 數據表中的 id 為 1 的數據進行查詢操作，此時的事務 B 會讀取 Undo  Log 中的數據并返回給客戶端，這就是 MySQL 中的 MVCC 機制。

可以在 MySQL 中通過下面的命令來查看控制 Undo Log 日志的參數。

show variables like  %innodb_undo%

Redo Log 日志

說了 MySQL 中的 Undo Log，我們再來看看 MySQL 中的 Redo Log 日志。

什么是 Redo Log

顧名思義 Redo  Log 的字面意思就是重做日志，指的是在數據庫出現意外情況時能夠對重新執行某種操作。在 MySQL 中，事務中修改的任何數據，都會將最新的數據寫入 Redo  Log 中進行備份。

在 MySQL 中，隨著事務操作的執行，就會產生 Redo Log 日志，在事務提交時會產生 Redo Log 并將其寫入 Redo Buffer，Redo  Buffer 也并不是隨著事務的提交就會被立刻寫入到磁盤中，而是等事務操作的臟頁寫入到磁盤之后，Redo Log 的使命也就完成了，此時，Redo  Log 日志占用的空間可以重新利用，會被后續產生的 Redo Log 日志覆蓋。

Redo Log 的原理

Redo Log 能夠實現事務的持久性，防止在發生故障的時間點，有臟頁未寫入表的 ibd 文件中，在重啟 MySQL 服務的時候，根據 Redo Log   進行重做，從而將未提交的事務進行持久化。這個過程可以簡化為下圖所示。

Redo Log 的寫機制

Redo Log 文件的內容是以順序循環的方式寫入文件的，寫滿時就會回到第一個文件，進行覆蓋寫。

Write Pos 是當前記錄的位置，一邊寫一邊后移，寫到最后一個文件末尾后就回到 0 號文件開頭;

CheckPoint 是當前要擦除的位置，也是往后推移并且循環的，擦除記錄前要把記錄更新到數 據文件;

Write Pos 和 CheckPoint 之間還空著的部分，可以用來記錄新的操作。如果 Write Pos 追上  CheckPoint，表示已經寫滿，此時就需要向后移動 CheckPoint 來擦除數據。

每個 InnoDB 存儲引擎至少有 1 個重做日志文件組(group)，每個文件組至少有 2 個重做日志文件，默認為 ib_logfile0 和 ib_logfile1  。

可以在 MySQL 中通過如下命令來查看控制 Redo Log 的參數。

show variables like  %innodb_log%

Redo Log 寫入機制

在 Redo Log 日志信息從 Redo Buffer 持久化到 Redo  Log 時，具體的持久化策略可以通過 innodb_flush_log_at_trx_commit 參數進行設置，具體策略如下所示。

0：每秒提交 Redo buffer – OS cache – flush cache to  disk，可能丟失一秒內的事務數據。由后臺 Master 線程每隔 1 秒執行一次操作。

1(默認值)：每次事務提交執行 Redo Buffer – OS cache – flush cache to  disk，這種方式最安全，性能最差。

2：每次事務提交執行 Redo Buffer – OS cache，然后由后臺 Master 線程再每隔 1 秒執行 OS cache –  flush cache to disk 的操作。

一般建議選擇取值 2，因為 MySQL 掛了數據沒有損失，整個服務器掛了才會損失 1 秒的事務提交數據。

Binlog 日志

什么是 Binlog

Binlog 記錄所有 MySQL 數據庫表結構變更以及表數據修改的二進制日志，不會記錄 select 和 show 這類查詢操作的日志。Binlog 日志是以事件形式記錄，還包含語句所執行的消耗時間。開啟 Binlog 日志有以下兩個最重要的使用場景。

主從復制：在主庫中開啟 Binlog 功能，這樣主庫就可以把 Binlog 傳遞給從庫，從庫拿到 Binlog 后實現數據恢復達到主從數據一致性。

數據恢復：通過 mysqlbinlog 等工具來恢復數據

Binlog 文件記錄模式

Binlog 文件記錄模式有 STATEMENT、ROW 和 MIXED 三種，具體含義如下。

ROW 模式

ROW(row-based replication, RBR)：日志中會記錄每一行數據被修改的情況，然后在 slave 端對相同的數據進行修改。

優點：能清楚記錄每一個行數據的修改細節，能完全實現主從數據同步和數據的恢復。

缺點：批量操作，會產生大量的日志，尤其是 alter table 會讓日志暴漲。

STATMENT 模式

STATMENT(statement-based replication,  SBR)：每一條被修改數據的 SQL 都會記錄到 master 的 Binlog 中，slave 在復制的時候 SQL 進程會解析成和原來 master 端執行過的相同的 SQL 再次執行。簡稱 SQL 語句復制。

優點：日志量小，減少磁盤 IO，提升存儲和恢復速度

缺點：在某些情況下會導致主從數據不一致，比如 last_insert_id()、now()等函數。

MIXED 模式

MIXED(mixed-based replication,  MBR)：以上兩種模式的混合使用，一般會使用 STATEMENT 模式保存 binlog，對于 STATEMENT 模式無法復制的操作使用 ROW 模式保存 binlog，MySQL 會根據執行的 SQL 語句選擇寫入模式  。

Binlog 文件結構

對于 MySQL 的 Binlog 文件結構有三種版本，見下圖。

關于 Binlog 文件結構的具體信息，小伙伴們可以參考 MySQL 的官方文檔，具體鏈接為：https://dev.mysql.com/doc/internals/en/event-header-fields.html

Binlog 寫機制

根據記錄模式和操作觸發 event 事件生成 log event(事件觸發執行機制)。

將事務執行過程中產生的日志時間 (log event) 寫入緩沖區，每個事務線程都有一個緩沖區。Log  Event 保存在一個 binlog_cache_mngr 數據結構中，在該結構中有兩個緩沖區，一個是 stmt_cache，用于存放不支持事務的信息; 另一個是 trx_cache，用于存放支持事務的信息。

事務在提交階段會將產生的 log event 寫入到外部 binlog 文件中。不同事務以串行方式將 log  event 寫入 Binlog 文件中，所以一個事務包含的 log event 信息在 binlog 文件中是連續的，中間不會插入其他事務的 log event。

Binlog 文件操作

Binlog 狀態查看

show variables like  log_bin

開啟 Binlog 功能，需要修改 my.cnf 或 my.ini 配置文件，在 [mysqld] 下面增加 log_bin=mysql_bin_log，重啟  MySQL 服務。

binlog-format=ROW log-bin=mysqlbinlog

使用 show binlog events 命令

show binary logs; // 等價于 show master logs; show master status; show binlog events; show binlog events in  mysqlbinlog.000001

使用 mysqlbinlog 命令

mysqlbinlog  文件名  mysqlbinlog  文件名     test.sql

使用 binlog 恢復數據

// 按指定時間恢復  mysqlbinlog --start-datetime= 2021-02-28 18:00:00  --stopdatetime= 2021-03-01 00:00:00  mysqlbinlog.000001 | mysql -uroot -p123456 // 按事件位置號恢復  mysqlbinlog --start-position=1789 --stop-position=2674 mysqlbinlog.000001 | mysql -uroot -p123456

刪除 Binlog 文件

purge binary logs to  mysqlbinlog.000001  // 刪除指定文件  purge binary logs before  2021-03-01 00:00:00  // 刪除指定時間之前的文件  reset master; // 清除所有文件

可以通過設置 expire_logs_days 參數來啟動自動清理功能。默認值為 0 表示沒啟用。設置為大于 0 的整數表示超出多少天 binlog 文件會自動清除。

感謝各位的閱讀，以上就是“有哪些關于 MySQL 日志”的內容了，經過本文的學習后，相信大家對有哪些關于 MySQL 日志這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是丸趣 TV，丸趣 TV 小編將為大家推送更多相關知識點的文章，歡迎關注！