MySQL中三大日志用法

• undolog日志是inndb存儲引擎層生成的日志，實現(xiàn)了事務(wù)的原子性，主要用于事務(wù)回滾和MVCC。
• redolog日志是inndb存儲引擎層生成的日志，實現(xiàn)了事務(wù)的持久性，主要用于掉電等故障恢復(fù)。
• binlog日志是Server層生成的日志，主要用于數(shù)據(jù)備份和主從復(fù)制。

undolog回滾日志

undolog是如何實現(xiàn)事務(wù)回滾和MVCC？

三個隱藏字段：事務(wù)id、回滾指針、主鍵（如果我們在表中沒有指定主鍵，則會創(chuàng)建一個默認的隱藏主鍵row_id,如果表中有主鍵，則不會創(chuàng)建）。

在我們開啟事務(wù)后，執(zhí)行事務(wù)的過程中，如果我們對數(shù)據(jù)進行增刪改操作，會先記錄undolog日志，記錄數(shù)據(jù)變更之前的信息，然后更新數(shù)據(jù)庫中的記錄，并且記錄本次操作的事務(wù)ID、回滾指針。通過回滾指針，我們可以構(gòu)建出每條記錄的版本鏈，即數(shù)據(jù)庫中每一條記錄的歷史版本信息。

通過構(gòu)建的版本鏈，如果我們在執(zhí)行事務(wù)的過程中發(fā)生了異常，這時候就會根據(jù)版本鏈的信息將每條記錄中回滾到舊值。

MVCC的實現(xiàn)是利用版本鏈和開啟ReadView快照讀時記錄的信息，根據(jù)一定的規(guī)則去判斷修改記錄的事務(wù)是否已經(jīng)提交。如果提交了，在讀已提交的隔離級別下就可以讀取到已提交事務(wù)的信息了；如果在可重復(fù)讀隔離級別下，則會在后續(xù)的ReadView中復(fù)用之前的視圖，只能看到第一次創(chuàng)建ReadView時候的數(shù)據(jù)信息。

redolog重做日志

為什么需要redolog,解決了什么問題？

我們做數(shù)據(jù)的增刪改操作時，并不是直接將數(shù)據(jù)寫入到磁盤中，而是先將數(shù)據(jù)寫入到Buffer Pool緩存中。如果我們每次將數(shù)據(jù)都寫入到磁盤，將會導(dǎo)致磁盤I/O頻繁，內(nèi)存開銷大。

有了Buffer Pool之后，我們的具體操作流程為：

• 讀取數(shù)據(jù)時，如果數(shù)據(jù)存在于Buffer Pool中，客戶端直接讀取Buffer Pool中的數(shù)據(jù)，否則再去磁盤中讀取。
• 當修改數(shù)據(jù)時，如果數(shù)據(jù)存在于Buffer Pool當中，那直接修改Buffer Pool所在的頁，然后將其頁設(shè)置為臟頁（該頁內(nèi)存數(shù)據(jù)和磁盤數(shù)據(jù)已經(jīng)不一致了）,為了減少磁盤I/O,不會立即將臟頁寫入到磁盤，后續(xù)由后臺線程在一個合適的時機將臟頁寫入磁盤。

引入Buffer Pool做數(shù)據(jù)緩存解決了頻繁讀寫I/O的問題，但是又導(dǎo)致了緩存中的數(shù)據(jù)和磁盤中的數(shù)據(jù)存在不一致的問題。即我們更新完緩存中的數(shù)據(jù)，這時候還沒來得及更新磁盤中的數(shù)據(jù)，mysql發(fā)生故障，導(dǎo)致緩存中的數(shù)據(jù)丟失，數(shù)據(jù)持久化失敗。

為了解決這個問題，MySQL在Innodb存儲引擎層引入了redolog日志。這時候，當有一條數(shù)據(jù)更新的時候，InnoDB引擎就會先更新內(nèi)存（同時標記為臟頁），然后將本次對這個頁的修改以redo log的形式記錄下來，這時候更新就算完成了。后續(xù)InnoDB存儲引擎會在后臺啟動一個線程，將redolog中的記錄寫入到磁盤中，并將binlog中已經(jīng)寫入磁盤的內(nèi)容清空，這時候更新操作最終完成。

有的同學(xué)可能會有疑問？我將更新的操作寫入到redolog中也是做磁盤的IO操作，為什么不直接將數(shù)據(jù)寫入到數(shù)據(jù)庫中呢？先寫入到redolog中，再寫入到數(shù)據(jù)庫中不是更加浪費開銷嗎？

要解答這個問題，首先我們需要先了解一下常見的兩種寫入磁盤的方式：

• 順序?qū)懭?/strong>：我們向磁盤中寫入數(shù)據(jù)遵循一定的規(guī)則，比如從頭到尾。
• 隨機寫入：我們向磁盤中寫入數(shù)據(jù)是隨機的，一會寫到這里，一會寫到那里。