一、mysql為什么需要undo log

MySQL是原地更新記錄的，事務的更新是直接作用到舊有記錄，舊有記錄被寫到undo。同時，它又是steal的，意味著未提交的數(shù)據(jù)可以被持久化。undo有兩個作用，名列前茅，必須要有辦法找回舊記錄以回滾事務。同時，需要保存舊記錄實現(xiàn)多版本。

當然，沒有undo的數(shù)據(jù)庫也有，比如PostgreSQL。它不會原地更新，更新就是插入一個新版本。當然，這樣做的代價是浪費空間，失效記錄太多了就會影響效率，需要定期的垃圾回收。

在InnoDB中，有三種日志跟事務的ACID關系都很大：

可以看到，undo log只關心過去，redo log只關心未來

如果我們只記錄一個歷史版本數(shù)據(jù)，其它事務每次都只需要讀取到最新版本的數(shù)據(jù)，的確是這樣，這個就是Read Committed

但是，如果說你要備份整個數(shù)據(jù)庫，整個事務可能會持續(xù)一個小時，同時有大量線上并發(fā)修改操作，我相信你一定希望讀取到邏輯一致的數(shù)據(jù)。這時同一行數(shù)據(jù)就需要支持多個歷史版本的數(shù)據(jù)了，這一招叫MVCC，對應Repeatable Read隔離級別，而記錄多個歷史版本數(shù)據(jù)的地方就叫undo log

實踐中，對于面向個人業(yè)務的互聯(lián)網(wǎng)在線業(yè)務，推薦Read Committed；對于分析性業(yè)務，推薦Repeatable Read（InnoDB的默認事務隔離級別）

InnoDB將undo log作為數(shù)據(jù)的一部分存儲到了redo log中，因此很多時候不太區(qū)分它們。

延伸閱讀：

二、undo log的工作原理

在更新數(shù)據(jù)之前，MySQL會提前生成undo log日志，當事務提交的時候，并不會立即刪除undo log，因為后面可能需要進行回滾操作，要執(zhí)行回滾（rollback）操作時，從緩存中讀取數(shù)據(jù)。undo log日志的刪除是通過通過后臺purge線程進行回收處理的。

1、事務A執(zhí)行update操作，此時事務還沒提交，會將數(shù)據(jù)進行備份到對應的undo buffer，然后由undo buffer持久化到磁盤中的undo log文件中，此時undo log保存了未提交之前的操作日志，接著將操作的數(shù)據(jù)，也就是Teacher表的數(shù)據(jù)持久保存到InnoDB的數(shù)據(jù)文件IBD。

2、此時事務B進行查詢操作，直接從undo buffer緩存中進行讀取，這時事務A還沒提交事務，如果要回滾（rollback）事務，是不讀磁盤的，先直接從undo buffer緩存讀取。