undo log介紹

大家不妨先思考下，如果事務中的SQL執(zhí)行到一半,遇到報錯，需要把前面已經執(zhí)行過的SQL撤銷以達到原子性的目的，這個過程也叫做"回滾"，該怎么實現(xiàn)呢？

每當我們要對一條記錄做改動時（這里的改動可以指INSERT、DELETE、UPDATE),把回滾時所需的東西記下來。比如：

• 你插入一條記錄時，至少要把這條記錄的主鍵值記下來，之后回滾的時候只需要把這個主鍵值對應的記錄刪

掉就好了

• 你刪除了一條記錄，至少要把這條記錄中的內容都記下來，這樣之后回滾時再把由這些內容組成的記錄插入

到表中就好了

• 你修改了一條記錄，至少要把修改這條記錄前的舊值都記錄下來，這樣之后回滾時再把這條記錄更新為舊值

MySQL把這些為了回滾而記錄的這些內容稱之為撤銷日志或者回滾日志, 即undo log 。

undo log存儲形式

undo log的日志內容是邏輯日志，非物理日志。

• 物理日志的意思是指具體的把具體某個數(shù)據(jù)頁上的某個偏移量的指改為什么，是具體到物理結構上了，比如redo log就是物理日志。
• 而邏輯日志只是記錄了某條數(shù)據(jù)的信息是怎么樣的，沒有到具體的物理磁盤上

InnoDB對undo log的管理采用段的方式，也就是回滾段（rollback segment） 。每個回滾段記錄了 1024 個 undo log segment ，每個事務只會使用一個回滾段，當一個事務開始的時候，會制定一個回滾段，在事務進行的過程中，當數(shù)據(jù)被修改時，原始的數(shù)據(jù)會被復制到回滾段。

在MySQL5.5的時候，只有一個回滾段，那么最大同時支持的事務數(shù)量為1024個。在MySQL 5.6開始，InnoDB支持最大 128個回滾段，故其支持同時在線的事務限制提高到了 128*1024 。

• insert undo log格式

記錄的是insert 語句對應的undo log，它生成的undo log記錄格式如下圖：

• update undo log格式

記錄的是update、delete 語句對應的undo log，它生成的undo log記錄格式如下圖：

那么上面這些生成undo log日志文件最終是存儲在哪的呢？

這些回滾段是存儲于共享表空間ibdata中。從MySQL5.6版本開始，可通過參數(shù)對rollback segment做進一步的設置。這些參數(shù)包括：

• innodb_undo_directory: 設置rollback segment文件所在的路徑。這意味著rollback segment可以存放在共享表空間以外的位置，即可以設置為獨立表空間。該參數(shù)的默認值為“/”，表示當前noDB存儲引擎的目錄。
• innodb_undo_logs: 設置rollback segment的個數(shù)，默認值為128。
• innodb_undo_tablespaces: 設置構成rollback segment文件的數(shù)量，這樣rollback segment可以較為平均地分布在多個文件中。設置該參數(shù)后，會在路徑innodb_undo_directory看到undo為前綴的文件，該文件就代表rollback segment文件。

事務回滾機制

對于InnoDB引擎來說，每個行記錄除了記錄本身的數(shù)據(jù)之外，還有幾個隱藏的列：

• DB_ROW_ID：如果沒有為表顯式的定義主鍵，并且表中也沒有定義唯一索引，那么InnoDB會自動為表添加一個row_id的隱藏列作為主鍵。
• DB_TRX_ID：每個事務都會分配一個事務ID,當對某條記錄發(fā)生變更時，就會將這個事務的事務ID寫入tx_id

中。

• DB_ROLL_PTR: 回滾指針，本質上就是指向undo log的指針。

• insert數(shù)據(jù)：

insert into user (name, sex) values('旭陽', '女')

插入的數(shù)據(jù)都會生成一條insert undo log，并且數(shù)據(jù)的回滾指針會指向它。undo log會記錄undo log的序號、插入主鍵的列和值...，那么在進行rollback的時候，通過主鍵直接把對應的數(shù)據(jù)刪除即可。

• update數(shù)據(jù)

update user set sex = '男' where id = 1;
update user set name = 'alvin' where id = 1;

這時會把老的記錄寫入新的undo log，讓回滾指針指向新的undo log，它的undo no是1，并且新的undo log會指向老的undo log（undo no=0），最終形成undo log版本鏈，如下圖所示：

可以發(fā)現(xiàn)每次對數(shù)據(jù)的變更都會產生一個undo log，當一條記錄被變更多次時，那么就會產生多條undo log，undo log記錄的是變更前的日志，并且每個undo log的序號是遞增的，那么當要回滾的時候，按照序號依次向前推，就可以找到我們的原始數(shù)據(jù)了。

那么按照上面的例子，事務要進行回滾，最終得到下面的執(zhí)行流程：

• 通過undo no=2的日志把id=1的數(shù)據(jù)的name還原成“旭陽"

• 通過undo no=1的日志把id=1的數(shù)據(jù)的sex還原成"女"

• 通過undo no=0的日志把id=1的數(shù)據(jù)根據(jù)主鍵信息刪除

undo log生命周期

生成過程

MySQL處于性能考慮，數(shù)據(jù)會優(yōu)先從磁盤加載到Buffer Pool中，在更新Buffer Pool中數(shù)據(jù)之前，會優(yōu)先將數(shù)據(jù)記錄到undo log中。

記錄undo log日志，MySQL不會直接去往磁盤中的xx.ibdata文件寫數(shù)據(jù)，而是會寫在undo_log_buffer緩沖區(qū)中，因為工作線程直接去寫磁盤太影響效率了，寫進緩沖區(qū)后會由后臺線程去刷寫磁盤。

刪除過程

現(xiàn)在我們已經明白了undo log日志是如何生成，并且作用于事務回滾的，那這些數(shù)據(jù)是什么時候刪除呢？

• 針對于insert undo log，因為insert操作的記錄，只對事務本身可見，對其他事務不可見。故該undo log在事務提交后就沒有用，就會直接刪除。

● 針對于update undo log，該undo log需要支持MVCC機制，因此不能在事務提交時就進行刪除。提交時放入undo log鏈表，有專門的purge線程進行刪除。

總結

本文詳細講解了MySQL中undo log日志的用處，以及它是如何保證事務的原子性。實際上，undo log也還有一個很重要的作用就是還對事務的隔離性實現(xiàn)起到作用，具體的在后面的MVCC機制中詳細說明。如果本文對你有幫助的話，請留下一個贊吧。

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

最新評論