MySQL中有六種日志文件，分別是：重做日志（redo log）、回滾日志（undo log）、二進制日志（binlog）、錯誤日志（errorlog）、慢查詢日志（slow query log）、一般查詢日志（general log），中繼日志（relay log）。

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

【undo log】

事務開始之前，將當前事務版本生成 undo log（Tips：undo log 也會產(chǎn)生 redo log 來保證 undo log 的可靠性）。

事務提交之后，undo log 并不能立馬被刪除，而是放入待清理的鏈表，由 purge 線程判斷是否有其它事務在使用 undo 段中表的上一個事務之前的版本信息，從而決定是否可以清理 undo log 的日志空間。

數(shù)據(jù)庫事務四大特性中有一個是 原子性 ，具體來說就是 原子性是指對數(shù)據(jù)庫的一系列操作，要么全部成功，要么全部失敗，不可能出現(xiàn)部分成功的情況。

實際上， 原子性 底層就是通過undo log實現(xiàn)的。undo log主要記錄了數(shù)據(jù)的邏輯變化，比如一條INSERT語句，對應一條DELETE的undo log，對于每個UPDATE語句，對應一條相反的UPDATE的undo log，這樣在發(fā)生錯誤時，就能回滾到事務之前的數(shù)據(jù)狀態(tài)。例如，user表中原記錄如下：

執(zhí)行sql update user set name = 'xiaohong' where id = 1; 的時候生成的undo log大概是update user set name = 'xiaoming' where id = 1;

同時，undo log也是MVCC(多版本并發(fā)控制)實現(xiàn)的關鍵。

【redo log】

mysql是如何保證事務的持久性的呢？最簡單的做法是在每次事務提交的時候，將該事務涉及修改的數(shù)據(jù)頁全部刷新到磁盤中。但是這么做會有嚴重的性能問題，主要體現(xiàn)在兩個方面：

• 因為Innodb是以頁為單位進行磁盤交互的，而一個事務很可能只修改一個數(shù)據(jù)頁里面的幾個字節(jié)，這個時候將完整的數(shù)據(jù)頁刷到磁盤的話，太浪費資源了！
• 一個事務可能涉及修改多個數(shù)據(jù)頁，并且這些數(shù)據(jù)頁在物理上并不連續(xù)，使用隨機IO寫入性能太差！

因此，mysql設計了redo log機制，并通過WAL（Write-Ahead Logging）技術進行了性能優(yōu)化。WAL的核心就是先順序IO寫日志磁盤、再隨機IO寫數(shù)據(jù)磁盤，節(jié)省的是隨機寫磁盤的 IO 消耗。mysql 每執(zhí)行一條 DML 語句，先將記錄順序追加寫入 redo log buffer并更新內存中的數(shù)據(jù)，等到有空閑線程、內存不足、Redo Log滿時再批量落盤持久化。

【binlog】

binlog是mysql的邏輯日志并且由Server層進行記錄，記錄對象為任意數(shù)據(jù)庫引擎的寫入性操作(不包括查詢)信息，以二進制的形式保存在磁盤中。

在實際應用中，binlog的主要使用場景有兩個，分別是 主從復制 和 數(shù)據(jù)恢復 。

• 主從復制 ：在Master端開啟binlog，然后將binlog發(fā)送到各個Slave端，Slave端重放binlog從而達到主從數(shù)據(jù)一致。
• 數(shù)據(jù)恢復 ：通過使用mysqlbinlog工具來恢復數(shù)據(jù)。

數(shù)據(jù)更新過程中，萬一更新數(shù)據(jù)的過程中系統(tǒng)出現(xiàn)故障異常重啟了，如何保證事務的持久性、原子性呢？概述如下：

1. 記錄此次更新前數(shù)據(jù)記錄的快照現(xiàn)場（即寫undo log）
2. 讀取此次更新所需要的數(shù)據(jù)入內存
3. 在內存中更新數(shù)據(jù)（效率高）
4. 寫redo log，并置redo log狀態(tài)為prepare
5. 寫binlog
6. 置redo log狀態(tài)為commit　　　　　　　

基于上述簡化版的undo log、redo log和binlog的寫入流程，我們來梳理下原子性、持久性、一致性的可靠性保證：

A）假如是在步驟1/2/3中任一步驟發(fā)生故障，故障恢復后發(fā)現(xiàn)redo log中并無未完成的記錄，故障恢復后只需要回滾undo log恢復現(xiàn)場即可；

B）假如在步驟4/5中任一步驟發(fā)生故障，故障恢復后發(fā)現(xiàn)redo log處于prepare狀態(tài)，則進一步判斷是否已經(jīng)寫入binlog：

1. 若已經(jīng)寫入binlog，則重新執(zhí)行redo log的相關記錄直到成功達到commit狀態(tài)（主從的一致性）；
2. 若未寫入binlog，則回滾undo log恢復現(xiàn)場（原子性）；　　　　　　　
   

C）假如在步驟6發(fā)生故障，故障恢復后發(fā)現(xiàn)redo log處于commit狀態(tài)，表示過程全部正常完成，則什么都不需要做。

總結

到此這篇關于Mysql中undo、redo與binlog區(qū)別的文章就介紹到這了,更多相關Mysql中undo、redo與binlog區(qū)別內容請搜索本站以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持本站！

美國服務器租用

版權聲明：本站文章來源標注為YINGSOO的內容版權均為本站所有，歡迎引用、轉載，請保持原文完整并注明來源及原文鏈接。禁止復制或仿造本網(wǎng)站，禁止在非www.sddonglingsh.com所屬的服務器上建立鏡像，否則將依法追究法律責任。本站部分內容來源于網(wǎng)友推薦、互聯(lián)網(wǎng)收集整理而來，僅供學習參考，不代表本站立場，如有內容涉嫌侵權，請聯(lián)系alex-e#qq.com處理。