概念介紹：

我們知道，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日誌的資料請關注我們其它相關文章！