一、前言

• MySQL 整體來看，其實就有兩塊：一塊是Server層，它主要做的是MySQL功能層面的事情；還有一塊是引擎層，負責存儲相關的具體事宜。

• redo log 是 InnoDB 引擎特有的日志，而 Server 層也有自己的日志，稱為 binlog（歸檔日志）。

二、Redo log

 WAL技術的全稱是 Write-Ahead Logging，它的關鍵點就是先寫日志，再寫磁盤。

• 當有一條記錄需要更新的時候，InnoDB引擎就會先把記錄寫到redo log里面，并更新內存，這個時候更新就算完成了。同時，InnoDB引擎會在適當的時候，將這個操作記錄更新到磁盤里面，而這個更新往往是在系統比較空閑的時候做。

• InnoDB 的 redo log 是固定大小的，比如可以配置為一組 4 個文件，每個文件的大小是1GB，那么redo log總共就可以記錄 4GB 的操作。從頭開始寫，寫到末尾就又回到開頭循環寫。

• 

• write pos 是當前記錄的位置，一邊寫一邊后移，寫到第 3 號文件末尾后就回到0號文件開頭。checkpoint是當前要擦除的位置，也是往后推移并且循環的，擦除記錄前要把記錄更新到數據文件。

• write pos和checkpoint之間的是“粉板”上還空著的部分，可以用來記錄新的操作。如果write pos追上checkpoint，表示“粉板”滿了，這時候不能再執行新的更新，得停下來先擦掉一些記錄，把 checkpoint 推進一下。

• 有了 redo log，InnoDB就可以保證即使數據庫發生異常重啟，之前提交的記錄都不會丟失，這個能力稱為 crash-safe。

三、Binlog

3.1 為什要有binlog還需要redo log呢？

因為最開始 MySQL 里并沒有 InnoDB 引擎。MySQL 自帶的引擎是 MyISAM，但是 MyISAM 沒有 crash-safe 的能力，binlog 日志只能用于歸檔。而 InnoDB 是另一個公司以插件形式引入 MySQL 的，既然只依靠 binlog 是沒有 crash-safe 能力的，所以 InnoDB 使用另外一套日志系統，也就是 redo log 來實現 crash-safe 能力。

3.2 Binlog和Redo log區別？

• redo log 是InnoDB 引擎特有的；binlog是MySQL的Server 層實現的，所有引擎都可以使用。

• redo log 是物理日志，記錄的是“在某個數據頁上做了什么修改”；binlog是邏輯日志，記錄的是這個語句的原始邏輯，比如“給 ID=2這一行的 c 字段加 1 ”。

• redo log 是循環寫的，空間固定會用完；binlog是可以追加寫入的?！白芳訉憽笔侵竍inlog文件寫到一定大小后會切換到下一個，并不會覆蓋以前的日志。

四、Undo log

4.1 什么是多版本并發控制（MVCC）？

可重復讀為例：在 MySQL 中，實際上每條記錄在更新的時候都會同時記錄一條回滾操作。記錄上的最新值，通過回滾操作，都可以得到前一個狀態的值。

假設一個值從1被按順序改成了2、3、4，在回滾日志里面就會有類似下面的記錄。

當前值是 4，但是在查詢這條記錄的時候，不同時刻啟動的事務會有不同的read-view。如圖中看到的，在視圖A、B、C里面，這一個記錄的值分別是1、2、4，同一條記錄在系統中可以存在多個版本，就是數據庫的多版本并發控制（MVCC）。對于 read-view A，要得到1，就必須將當前值依次執行圖中所有的回滾操作得到。

• 同時你會發現，即使現在有另外一個事務正在將 4 改成 5，這個事務跟 read-viewA、B、C對應的事務是不會沖突的。

• 系統會判斷，當沒有事務再需要用到這些回滾日志時，回滾日志會被刪除。即系統里沒有比這個回滾日志更早的read-view 的時候。

4.2 什么是undo log？

• InnoDB 里面每個事務有一個唯一的事務 ID，叫作 transaction id。它是在事務開始的時候向 InnoDB 的事務系統申請的，是按申請順序嚴格遞增的。

• 而每行數據也都是有多個版本的。每次事務更新數據的時候，都會生成一個新的數據版本，并且把 transaction id 賦值給這個數據版本的事務 ID，記為 row trx_id。同時，舊的數據版本要保留，并且在新的數據版本中，能夠有信息可以直接拿到它。

• 也就是說，數據表中的一行記錄，其實可能有多個版本 (row)，每個版本有自己的 row trx_id。

如圖 所示，就是一個記錄被多個事務連續更新后的狀態:圖中虛線框里是同一行數據的 4 個版本，當前最新版本是 V4，k 的值是 22，它是被 transaction id 為 25 的事務更新的，因此它的 row trx_id 也是 25。

你可能會問，前面的文章不是說，語句更新會生成 undo log（回滾日志）嗎？那么，undo log 在哪呢？

實際上，上圖中的三個虛線箭頭，就是 undo log；而 V1、V2、V3 并不是物理上真實存在的，而是每次需要的時候根據當前版本和undo log 計算出來的。比如，需要 V2 的時候，就是通過 V4 依次執行 U3、U2 算出來。