推薦學習：mysql影片教學
REDO LOG稱為重做日誌，當MySQL伺服器意外崩潰或宕機後，保證已提交的交易持久化到磁碟中（持久性）。
InnoDB是以頁為單位去操作記錄的，增刪改查都會加載整個頁到buffer pool中（磁碟->內存），事務中的修改操作並不是直接修改磁碟中的數據，而是先修改記憶體中buffer pool中的數據，後台執行緒每隔一段時間再異步刷新到磁碟中。
buffer pool：可存放索引、數據，可加速讀寫，直接在記憶體中操作資料頁，有專門的執行緒去把buffer pool中的髒頁寫入磁碟。
為什麼不直接修改磁碟中的資料？
因為直接修改磁碟資料的話，它是隨機IO，修改的資料分佈在磁碟中不同的位置，需要來回的查找，所以命中率低，消耗大，而且一個小小的修改就不得不將整個頁刷新到磁碟，利用率低；
與之相對的是順序IO，磁碟的資料分佈在磁碟的一塊，所以省去了查找的過程，節省尋道時間。
使用後台執行緒以一定的頻率去刷新磁碟可以降低隨機IO的頻率，增加吞吐量，這是使用buffer pool的根本原因。
修改記憶體再異步同步到磁碟的問題：
因為buffer pool是在記憶體中的區域，系統意外崩潰的話資料有可能會遺失，有些髒資料可能會來不及刷新到磁碟，事務的持久性得不到保證。因此，引入了redo log。修改資料時，額外記錄一次日誌，內容是xx頁xx偏移量發生了xx變化，當系統崩潰時可以根據日誌內容進行恢復。
寫日誌和直接刷新磁碟的差別是：寫日誌是追加寫入，順序IO，速度更快，且寫入的內容相對更小
redo log由兩部分組成：
#修改操作大致流程：
第1步：先將原始資料從磁碟讀入記憶體中來，修改資料的記憶體拷貝，產生髒資料
第2步：產生一條重做日誌並寫入redo log buffer，記錄的是資料被修改後的值
第3步：預設在交易提交後將redo log buffer中的內容刷新到redo log file，對redo log file採用追加寫的方式
第4步：定期將內存中修改的資料刷新到磁碟中（這裡說的是那些還沒及時被後台線程刷碟的髒資料）
通常所說的Write-Ahead Log(預先日誌持久化)指的是在持久化一個資料頁之前，先將記憶體中對應的日誌頁持久化。
redo log的好處：
redo log一定能保證交易的持久性嗎？
不一定，這要根據redo log的刷盤策略決定，因為redo log buffer同樣是在內存中，如果提交事務之後，redo log buffer還沒來得及將數據刷新到redo log file進行持久化，此時發生宕機照樣會遺失資料。如何解決？刷盤策略。
InnoDB中給出了innodb_flush_log_at_trx_commit參數控制redo log buffer刷新到redo log file時的三種策略：
值為0的情況：
因為有1s的間隔，所以最壞情況下會遺失1秒的資料。
值為1的情況：
commit時需要先主動刷新redo log buffer到redo log file，如果中途宕機了，事務也就失敗了，不會有任何損失，真正能保證事務的持久性。但是效率最差。
值為2的情況：是根據os決定。
可以調整為0或2提高交易的效能，但是喪失了ACID特性
undo log用來保證交易的原子性和一致性。作用有兩個：①提供回滾操作②多版本控制MVVC
回滾操作
前面redo log中說過，後台執行緒會不定時的去刷新buffer pool中的數據到磁碟，但是如果該事務執行期間出現各種錯誤(宕機)或者執行rollback語句，那麼前面刷進去的操作都是需要回滾的，保證原子性，undo log就是提供事務回滾的。
MVVC
當讀取的某一行被其他事務鎖定時，它可以從undo log分析出該行記錄先前的資料版本是怎樣的，從而讓使用者能夠讀取到目前事務操作之前的資料——快照讀取。
快照讀：SQL讀取的資料是歷史版本，不用加鎖，普通的SELECT就是快照讀。
undo log的組成部分：
select作業不會產生undo log
在InnoDB儲存引擎中，undo log使用rollback segment回滾段進行存儲，每隔回滾段包含了1024個undo log segment。 MySQL5.5之後，總共有128個回滾段。即總共可以記錄128 * 1024個undo操作。
每個交易只會使用一個回滾段，一個回滾段在同一時刻可能會服務多個交易。
交易提交後無法立即刪除該undo log，可能有些事務會想要讀取先前的資料版本（快照讀取）。所以事務提交時將undo log放入一個鍊錶中，稱為版本鏈，undo log的刪除與否由一個稱為purge的執行緒判斷。
undo log分為：
insert undo log
因為insert操作的記錄，只對事務本身可見，對其他事務不可見(這是事務隔離性的要求)，故該undo log可以在交易提交後直接刪除。不需要進行purge操作。
update undo log
update undo log記錄的是對delete和update作業產生的undo log。此undo log可能需要提供MVCC機制，因此無法在交易提交時就進行刪除。提交時放入undo log鍊錶，等待purge執行緒進行最後的刪除。
假設有2個數值，分別為A=1和B=2，然後某個交易將A修改為3，B修改為4，修改過程可簡化為：
1.begin
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
對於InnoDB引擎來說，每個行記錄除了記錄本身的資料之外，還有幾個隱藏的列:
當我們執行INSERT：
begin; INSERT INTO user (name) VALUES ('tom');
插入的資料都會產生一條insert undo log，並且資料的回滾指標會指向它。 undo log會記錄undo log的序號、插入主鍵的列和值...，那麼在進行rollback的時候，透過主鍵直接把對應的資料刪除即可。
當我們執行UPDATE時：
對於更新的操作會產生update undo log，並且會分更新主鍵的和不更新主鍵的，假設現在執行:
UPDATE user SET name='Sun' WHERE id=1;
這時會把新的undo log記錄加入到版本鏈中，它的undo no是1，並且新的undo log的回滾指針會指向老的undo log (undo no=0)。
假設現在執行：
UPDATE user SET id=2 WHERE id=1;
對於更新主鍵的操作，會先把原來的資料deletemark標識打開，這時並沒有真正的刪除數據，真正的刪除會交給清理線程去判斷，然後在後面插入一條新的數據，新的數據也會產生undo log，並且undo log的序號會遞增。
可以發現每次對資料的變更都會產生一個undo log，當一筆記錄被變更多次時，那麼就會產生多個undo log，undo log記錄的是變更前的日誌，並且每個undo log的序號是遞增的，那麼當要回滾的時候，按照序號依序向前推，就可以找到我們的原始資料了。
以上面的範例來說，假設執行rollback，那麼對應的流程應該是這樣：
1. 透過undo no= 3的日誌把id=2的資料刪除
2. 透過undo no=2的日誌把id=1的資料的deletemark還原成0
3. 透過undo no=1的日誌把id=1的資料的name還原成Tom
4. 透過undo no=0的日誌把id=1的資料刪除
MySQL MVVC多版本並發控制
binlog即binary log，二進位日誌文件，也叫作變更日誌（update log）。它記錄了資料庫所有執行的更新語句。
binlog主要應用場景：
show variables like '%log_bin%';
查看bin log日誌:
mysqlbinlog -v "/var/lib/mysql/binlog/xxx.000002"
使用日誌復原資料:
mysqlbinlog [option] filename|mysql –uuser -ppass;
刪除二進位日誌:
PURGE {MASTER | BINARY} LOGS TO ‘指定日志文件名'
PURGE {MASTER | BINARY} LOGS BEFORE ‘指定日期'事務執行過程中，先把日誌寫到bin log cache ，交易提交的時候，再把binlog cache寫到binlog檔。因為一個事務的binlog不能被拆開，無論這個事務多大，也要確保一次性寫入，所以系統會給每個執行緒分配一個區塊記憶體作為binlog cache。
兩個重點也不同， redo log讓InnoDB有了崩潰復原的能力，binlog保證了MySQL叢集架構的資料一致性。
在執行更新語句過程，會記錄redo log與binlog兩塊日誌，以基本的事務為單位，redo log在事務執行過程中可以不斷寫入，而binlog只有在提交事務時才寫入，所以redo log與binlog的寫入時機不一樣。
redo log與binlog兩份日誌之間的邏輯不一致，會出現什麼問題？
以update語句為例，假設id=2的記錄，字段c值是0，把字段c值更新成1，SQL語句為update T set c=1 where id=2。
假設執行過程中寫完redo log日誌後，binlog日誌寫期間發生了異常，會出現什麼情況呢?
#由於binlog沒寫完就異常，這時候binlog裡面沒有對應的修改紀錄。因此，之後用binlog日誌恢復資料或slave讀取master的binlog時，就會少這次更新，恢復出來的這一行c值是0，而原庫因為redo log日誌恢復，這一行c值是1，最終數據不一致。
為了解決兩份日誌之間的邏輯一致性問題，InnoDB儲存引擎使用兩階段提交方案。將redo log拆成了兩個步驟prepare和commit，這就是兩階段提交。
讓redo log和bin log最終的提交綁定到一起，前面說過的，事務commit時預設需要讓redo log先同步完才算commit成功，所以如果綁定到一起的話，bin log也具有該特性了，就保證了資料不會遺失。
使用兩階段提交後，寫入binlog時發生異常也會有影響，因為MySQL根據redo log日誌復原資料時發現redo log仍處於prepare階段，且沒有對應binlog日誌，就會提交失敗，回溯資料。
另一個場景，redo log的commit階段發生異常，那會不會回溯事務呢？
並不會回滾事務，它會執行上圖框住的邏輯，雖然redo log是處於prepare階段，但是能透過交易id找到對應的binlog日誌，所以MySQL認為是完整的，就會提交交易恢復資料。
推薦學習：mysql影片教學
#以上是MySQL日誌專題整理之redo log和undo log的詳細內容。更多資訊請關注PHP中文網其他相關文章！
