概念介紹：

我們知道，MySQL中的redo日志記錄了事務的行為，在服務器宕機的時候，可以通過重做事務來達到恢復數據的目的，然而，有的時候，事務還有回滾的需求，也就是說，我們需要知道某條在變成當前情況之前的樣子，這種情況下，undo日志就派上用場了。也就是說，undo日志是為了將數據恢復到修改之前的樣子，因此在對數據庫進行修改的時候，我們需要知道，這個過程中會產生redo日志和undo日志。

存儲位置：

我們還知道，redo日志一般情況下放在redo日志文件中，也就是常說的ib_log中，而undo日志存放在數據庫內部的一個"段"中，這個概念，我們在8月21號的文章中有講過，忘記的同學可以回去看看，undo日志的段位于共享表空間內。

回滾操作：

現在，我們已經知道了undo的概念，其實就是共享表空間中的一塊區域，它的主要作用是將事務恢復到執行修改之前的樣子，但是，恢復的情況一般分為兩種，一種是邏輯恢復，一種是物理恢復，這里需要非常強調的是，undo的恢復是邏輯恢復，也就是說，如果你插入了100w條數據，導致innodb分配了一個新的數據頁來存儲這些數據，那么在事務進行回滾的時候，undo的功能并不是回收這個數據頁，而是將這些insert的操作，改變成delete的操作從而執行回滾。在這個過程中，共享表空間的大小并不會發生改變。除此之外，undo日志會將delete操作轉化為insert操作，update操作轉化為反向的update操作。

刪除方式：

還有一點需要注意，事務共享表空間中寫入undo日志的過程同樣需要寫入redo日志，事務一旦提交，也就意味著事務的持久性生效，那么undo日志則不被需要，但是innodb并不會把這個undo日志直接刪除，而是放在一個undo日志的鏈表中，到底什么時候刪除取決于mysql的purge線程，這樣做是為了避免其他的事務需要通過undo日志來得到這條記錄之前的版本。

空間分配：

在實際操作中，一個數據庫實例上可能會進行很多事務，如果我們為每一個事務都分配單獨的日志數據頁來保存undo將會非常的浪費存儲空間，我們簡單算一算，假設一個應用的TPS為1000，為每個事務分配一個undo頁，我們之后到一個數據頁的大小是16kb，1分鐘將會產生60*1000個數據頁，那么一分鐘大約需要的空間就是960M的磁盤空間，這樣顯然是不合理的，因此，在innodb中，對于undo頁可以進行重用，具體的方法是，事務提交的時候，現將undo頁放入鏈表中，然后判斷這個undo頁的使用空間是否小于75%,如果是的話，那么這個undo頁就可以被重用，之后的undo日志就可以追加在當前undo日志的后面。當然，我們可以通過show engine innodb status來查看鏈表中undo log 的數量，這里不做演示了。

以上就是MySQL中的undo日志的詳細內容，更多關于MySQL undo日志的資料請關注腳本之家其它相關文章！