1.binlog（二進制日志）

MySQL中的binlog，全稱為Binary Log（二進制日志），是MySQL數(shù)據(jù)庫的一種日志文件，主要記錄了數(shù)據(jù)庫中所有修改了數(shù)據(jù)的SQL語句或者二進制的事件，用來保證數(shù)據(jù)的一致性與恢復。具體來說，binlog記錄了所有的DDL（Data Definition Language，數(shù)據(jù)定義語言）和DML（Data Manipulation Language，數(shù)據(jù)操作語言）語句，但不包括純查詢語句（如SELECT）和一些無需修改數(shù)據(jù)的操作（如SHOW等）。binlog是MySQL復制和數(shù)據(jù)恢復的基礎，具有以下幾個主要作用。

（1）數(shù)據(jù)復制：binlog是MySQL實現(xiàn)主從復制的基礎。在主從復制架構中，主服務器會記錄所有修改數(shù)據(jù)的操作到binlog中，而從服務器通過讀取這些binlog記錄并在自己的數(shù)據(jù)庫上重新執(zhí)行這些操作，從而實現(xiàn)與主服務器數(shù)據(jù)的同步。

（2）數(shù)據(jù)恢復：在數(shù)據(jù)庫發(fā)生故障時，可以使用binlog來進行點的恢復。例如，如果數(shù)據(jù)庫在某個時間點之后的數(shù)據(jù)因為操作錯誤或者其他原因被破壞，可以通過恢復到最近的備份，然后使用binlog中記錄的日志，重新執(zhí)行從備份時間點到故障時間點之間的所有操作，從而實現(xiàn)數(shù)據(jù)的恢復。

（3）審計：通過分析binlog的內容，可以查看在某個時間段內數(shù)據(jù)庫中發(fā)生了哪些數(shù)據(jù)修改操作，這對于跟蹤數(shù)據(jù)變更歷史、進行安全審計等都非常有用。

（4）增量備份：利用binlog可以實現(xiàn)增量備份，即備份自上次備份以來發(fā)生的所有數(shù)據(jù)變更。這種備份方式比完整備份更高效，尤其是在數(shù)據(jù)量大的情況下。

上圖表示了binlog 的四種讀寫作用場景，即數(shù)據(jù)恢復、數(shù)據(jù)復制（數(shù)據(jù)備份）、數(shù)據(jù)庫分布式讀寫、數(shù)據(jù)庫主從讀寫分離。

為了有效地使用binlog，需要在MySQL的配置文件（如my.cnf或my.ini）中開啟binlog，并配置相關參數(shù)，比如：

• log_bin：啟用binlog，并設置binlog文件的名稱。
• max_binlog_size：設置binlog文件的最大大小。
• binlog_format：設置binlog的格式，可以是STATEMENT（基于SQL語句）、ROW（基于行的變化）或MIXED（混合模式）。
• expire_logs_days：管理binlog還需要注意其大小，因為隨著時間的推移，binlog可能會占用大量磁盤空間。因此，需要定期清理或歸檔舊的binlog文件，以釋放空間并保持系統(tǒng)性能?？梢酝ㄟ^設置expire_logs_days參數(shù)來自動刪除過期的binlog文件。

Statement每一條會修改數(shù)據(jù)的sql都會記錄在binlog中。
優(yōu)點：不需要記錄每一行的變化，減少了binlog日志量，節(jié)約了IO，提高性能。
Row5.1.5版本的MySQL才開始支持row level 的復制，它不記錄sql語句上下文相關信息，僅保存哪條記錄被修改。
優(yōu)點：row level 的日志內容會非常清楚的記錄下每一行數(shù)據(jù)修改的細節(jié)。而且不會出現(xiàn)某些特定情況下的存儲過程，或function，以及trigger的調用和觸發(fā)無法被正確復制的問題。
Mixed從5.1.8版本開始，MySQL提供了Mixed格式，實際上就是Statement與Row的結合。

2.錯誤日志

MySQL的錯誤日志是MySQL數(shù)據(jù)庫中用于記錄數(shù)據(jù)庫啟動、運行或停止時出現(xiàn)的問題的日志文件。這些記錄包括MySQL服務器的各種錯誤、警告和重要的系統(tǒng)信息，對數(shù)據(jù)庫管理員進行故障排查和性能調優(yōu)非常有用。錯誤日志具有以下幾個重要作用。

（1）故障診斷

• 錯誤日志提供了關于MySQL服務器運行中發(fā)生的錯誤的詳細信息，如啟動失敗、連接錯誤、語法錯誤等。
• 管理員可以通過查看錯誤日志中的錯誤信息，快速定位問題的原因，進而采取相應的解決措施。

（2）系統(tǒng)檢控

• 通過定期檢查錯誤日志，可以及時發(fā)現(xiàn)并處理潛在的問題，如配置錯誤、性能瓶頸或安全風險。
• 錯誤日志中的信息可以幫助管理員了解系統(tǒng)的運行狀態(tài)，從而進行優(yōu)化和調整。

（3）恢復參考

• 在發(fā)生系統(tǒng)崩潰或意外中斷的情況下，錯誤日志可以提供崩潰前的最后活動記錄，這對于數(shù)據(jù)恢復和系統(tǒng)重啟有重要參考價值。

啟用錯誤日志

在MySQL的配置文件（通常是my.cnf或my.ini）中，可以設置錯誤日志的文件路徑：

[mysqld]
log_error = /path/to/your/log-file.err

如果沒有明確設置log_error選項，MySQL通常會在數(shù)據(jù)目錄中自動創(chuàng)建一個錯誤日志文件。錯誤日志的查看可以直接通過訪問其文件路徑來進行，或者通過相關的管理工具來查看。隨著運行時間的增長，錯誤日志的大小可能會增長很快，特別是在出現(xiàn)很多錯誤或警告的情況下。定期輪換和備份日志文件是一個好習慣，可以使用如logrotate這樣的工具來幫助管理日志文件。

3.事務日志

mysql的事務有 4 種特性：原子性、一致性、隔離性和持久性。那么事務的四種特性到底是基于什么機制實現(xiàn)呢？

事務的隔離性由鎖機制實現(xiàn)。

而事務的原子性、一致性和持久性由事務的 redo 日志和 undo 日志來保證。

• Redo Log：又稱為重做日志，提供再寫入操作，恢復提交事務修改的頁操作，用來保證事務的持久性。記錄的是物理級別上的頁修改操作，比如頁號xxx、偏移量 yyy 寫入了 ‘zzz’ 數(shù)據(jù)。主要為了保證數(shù)據(jù)的可靠性；
• Undo Log：又稱為回滾日志，回滾行記錄到某個特定版本，用來保證事務的原子性、一致性。記錄的是邏輯操作日志，比如對某一行數(shù)據(jù)進行了 INSERT 語句操作，那么 undo log 就記錄一條與之相反的 DELETE 操作。主要用于事務的回滾（undo log 記錄的是每個修改操作的逆操作）和一致性非鎖定讀（undo log 回滾行記錄到某種特定的版本—MVCC，即多版本并發(fā)控制）

3.1Redo日志

InnoDB 存儲引擎是以頁為單位來管理存儲空間的。在真正訪問頁面之前，需要把在磁盤上的頁緩存到內存中的 Buffer Pool 之后才可以訪問。所有的變更都必須先更新緩沖池中的數(shù)據(jù)，然后緩沖池中的臟頁會以一定的頻率被刷入磁盤（checkPoint 機制），通過緩沖池來優(yōu)化 CPU 和磁盤之間的鴻溝，這樣就可以保證整體的性能不會下降太快。

InnoDB 引擎的事務采用了 WAL 技術 (Write-Ahead Logging )，這種技術的思想就是先寫日志，再寫磁盤，只有日志寫入成功，才算事務提交成功，這里的日志就是 redo log。當發(fā)生宕機且數(shù)據(jù)未刷到磁盤的時候，可以通過 redo log 來恢復，保證 ACID 中的 D，這就是 redo log 的作用。

redo日志的組成

Redo log 可以簡單分為以下兩個部分：

（1）重做日志緩沖 (redo log buffer)，保存在內存中，是易失的。在服務器啟動時就向操作系統(tǒng)申請了一大片稱之為 redo log buffer 的連續(xù)內存空間，翻譯成中文就是 redo 日志緩沖區(qū)。這片內存空間被劃分成若干個連續(xù)的 redo log block。一個 redo log block 占用 512 字節(jié)大小。

（2）重做日志文件 (redo log file)，保存在硬盤中，是持久的。

redo的整體流程如下圖

第 1 步：先將原始數(shù)據(jù)從磁盤中讀入內存中來，修改數(shù)據(jù)的內存拷貝；

第 2 步：生成一條重做日志并寫入 redo log buffer，記錄的是數(shù)據(jù)被修改后的值；

第 3 步：當事務 commit 時，將 redo log buffer 中的內容刷新到 redo log file，對 redo log file采用追加寫的方式；

第 4 步：定期將內存中修改的數(shù)據(jù)刷新到磁盤中；

3.2Undo日志

undo log 是事務原子性的保證。在事務中更新數(shù)據(jù)的前置操作其實是要先寫入一個 undo log。

（1）事務需要保證原子性，也就是事務中的操作要么全部完成，要么什么也不做。但有時候事務執(zhí)行到一半會出現(xiàn)一些情況，比如：

情況一：事務執(zhí)行過程中可能遇到各種錯誤，比如服務器本身的錯誤， 操作系統(tǒng)錯誤 ，甚至是突然斷電導致的錯誤。

情況二：程序員可以在事務執(zhí)行過程中手動輸入 ROLLBACK 語句結束當前事務的執(zhí)行。

（2）以上情況出現(xiàn)，我們需要把數(shù)據(jù)改回原先的樣子，這個過程稱之為回滾，這樣就可以造成一個假象：這個事務看起來什么都沒做，所以符合原子性要求。

（3）每當我們要對一條記錄做改動時（這里的改動可以指 INSERT、DELETE、UPDATE，不包括 SELECT），都需要"留一手"——即把回滾時所需的東西記下來。比如：

你插入一條記錄時，至少要把這條記錄的主鍵值記下來，之后回滾的時候只需要把這個主鍵值對應的記錄融掉就好了。(對于每個INSERT，InnoDB 存儲引擎會完成一個DELETE）

你刪除了一·條記錄，至少要把這條記錄中的內容都記下來，這樣之后回滾時再把由這些內容組成的記錄插入到表中就好了。（對于每個DELETE，InnoDB 存儲引擎會執(zhí)行一個 INSERT）你修改了一個記錄，至少要把修改這條記錄前的舊值都記錄下來，這樣之后回滾時再把這條記錄更新為舊值就好了。（對于每個UPDATE，InnoDB 存儲引擎會執(zhí)行一個相反的 UPDATE，將修改前的行放回去）

（4）MySQL 把這些為了回滾而記錄的這些內容稱之為撤銷日志或者回滾日志（即 undo log）。注意，由于查詢操作 (SELECT) 并不會修改任何用戶記錄，所以在查詢操作執(zhí)行時，并不需要記錄相應的 undo 日志。此外，undo log 會產(chǎn)生 redo log，也就是 undo log 的產(chǎn)生會伴隨著 redo log 的產(chǎn)生，這是因為 undo log 也需要持久性的保護。

undo+redo日志生成過程（簡要）

（1）假設有 2 個數(shù)值，分別為 A = 1 和 B = 2，然后將 A 修改為3 ，B 修改為 4。

1. start transaction;
2. 記錄 A = 1 到 undo log;
3. update A = 3;
4. 記錄 A = 3 到 redo log;
5. 記錄 B = 2 到 undo log;
6. update B =4;
7. 記錄 B = 4 到 redo log;
8. 將 redo log 刷新到磁盤;
9. commit;

在 1 ~ 8 步驟的任意一步系統(tǒng)宕機，事務未提交，該事務就不會對磁盤上的數(shù)據(jù)做任何影響。
如果在 8 ~ 9 之間宕機，恢復之后可以選擇回滾，也可以選擇繼續(xù)完成事務提交
因為此時 redo log 已經(jīng)持久化。若在 9 之后系統(tǒng)宕機，內存映射中變更的數(shù)據(jù)還來不及刷回磁盤，那么系統(tǒng)恢復之后，可以根據(jù) redo log 把數(shù)據(jù)刷回磁盤。

4.慢查詢日志

MySQL的慢查詢日志是MySQL提供的一種日志類型，用于記錄執(zhí)行時間超過特定閾值的SQL查詢。這個功能主要用來識別數(shù)據(jù)庫操作中的性能瓶頸，從而幫助數(shù)據(jù)庫管理員優(yōu)化查詢語句和改進數(shù)據(jù)庫性能，其主要作用如下：

（1）性能分析

• 慢查詢日志提供了一個記錄所有執(zhí)行時間超過預設閾值的SQL語句的機制。這使得開發(fā)者和數(shù)據(jù)庫管理員能夠識別和優(yōu)化那些對性能影響最大的查詢。

（2）優(yōu)化數(shù)據(jù)庫

• 通過分析慢查詢日志中的信息，可以確定需要添加索引的地方、需要改寫的查詢、可能存在的表設計問題等。這有助于減少數(shù)據(jù)庫的響應時間和提升應用的整體性能。

（3）監(jiān)控與警報

• 在一些高級的監(jiān)控系統(tǒng)中，慢查詢日志可以被用作生成性能警報的依據(jù)，及時通知管理員采取行動。

如何啟用慢查詢日志及其相關參數(shù)

（1）啟用慢查詢日志

在MySQL的配置文件（通常是my.cnf或my.ini）中設置以下參數(shù)以啟用慢查詢日志：

[mysqld]
slow_query_log = 1
slow_query_log_file = /path/to/your/log-file
long_query_time = 2

其中，slow_query_log用于啟用慢查詢日志，slow_query_log_file指定日志文件的存儲位置，long_query_time設置查詢執(zhí)行的時間閾值（單位是秒），超過這個時間的查詢會被記錄。

總結

到此這篇關于Mysql數(shù)據(jù)庫中的各種日志的文章就介紹到這了,更多相關Mysql各種日志內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論