InnoDB undo tablespace使用及原理

前言

Undo log是InnoDB MVCC事務(wù)特性的重要組成部分，對記錄做了變更操作時會產(chǎn)生undo記錄，默認(rèn)存儲到系統(tǒng)表空間中，但是從5.6開始，可以使用獨(dú)立的undo表空間。

Undo記錄存儲的是老版本數(shù)據(jù)，當(dāng)一個舊事務(wù)需要讀取數(shù)據(jù)時，為了能讀取到老版本數(shù)據(jù)，需要順著undo連找到滿足其可見性的記錄。當(dāng)版本鏈很長時，可以認(rèn)為這是要一個比較耗時的操作。

大多數(shù)對記錄的變更insert、update、delete。Insert操作在事務(wù)提交前只對當(dāng)前事務(wù)可見，因此產(chǎn)生的undo日志可以在事務(wù)提交后直接刪除（沒有對剛插入的數(shù)據(jù)有可見性需求），而對于update、delete則需要維護(hù)多版本信息。

Undo tablespace

MySQL5.6可以使用獨(dú)立undo表空間。innodb_undo_tablespaces：0-126，在系統(tǒng)初始化后該文件大小默認(rèn)是10M。雖然可以將其從系統(tǒng)表空間提出了，使系統(tǒng)表空間不再因?yàn)榇笫聞?wù)而迅速不斷增大，但是獨(dú)立出來的undo表空間仍然比較雞肋，不能truncate。而且也沒有相關(guān)undo表空間文件大小的閾值。

MySQL5.7.5之后undo表空間可以truncate了。需要配置至少2個undo表空間innodb_undo_spaces=2，undo表空間被刪除時臨時設(shè)置為offline狀態(tài)，至少有另外一個undo表空間服務(wù)才可以讓server工作。如果配置成1個undo表空間的話，即使開啟truncate也沒用，本undo表空間文件會一直增大，甚至撐爆磁盤。

Mysql5.7.5之后版本，set global innodb_undo_log_truncate=on開啟truncate功能，innodb_max_undo_log_size為undo表空間文件的閾值，默認(rèn)1G，超過改值，會自動進(jìn)行truncate。如果不開啟truncate則導(dǎo)致undo表空間文件不斷增大。

被選中刪除的undo文件，對應(yīng)的回滾段標(biāo)記為inactive，purge回收不再使用的回滾段，完成后進(jìn)行truncate，恢復(fù)到10M大小，回滾段再次標(biāo)記為active。

innodb_undo_logs定義了InnoDB使用的回滾段個數(shù)，必須設(shè)置35個以上；第一個常駐系統(tǒng)表空間，若使用獨(dú)立undo表空間，則第一個置為inactive?；貪L段2-33在共享臨時表空間ibtmp1。34th 35th分別是獨(dú)立表空間的第一個和第二個。

undo tablesapce和回滾段之間什么關(guān)系

可以看到在系統(tǒng)啟動的時候創(chuàng)建好undo表空間。默認(rèn)undo表空間放到系統(tǒng)表空間里面。當(dāng)將undo表空間獨(dú)立出來時，undo表空間輪流分給各個回滾段。

可以看到當(dāng)undo表空間提出了的時候，回滾段是輪詢分配給每個事務(wù)的，并且不使用系統(tǒng)表空間，保證所有的undo log都存儲到undo 獨(dú)立表空間中。