概念介紹：

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

存儲位置：

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

回滾操作：

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

刪除方式：

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

空間分配：

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

以上就是MySQL中的undo日志的詳細內(nèi)容，更多關于MySQL undo日志的資料請關注好吧啦網(wǎng)其它相關文章！