InnoDB undo tablespace使用及原理

前言

Undo log是InnoDB MVCC事務特性的重要組成部分，對記錄做了變更操作時會產生undo記錄，默認存儲到系統表空間中，但是從5.6開始，可以使用獨立的undo表空間。

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

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

Undo tablespace

MySQL5.6可以使用獨立undo表空間。innodb_undo_tablespaces：0-126，在系統初始化后該文件大小默認是10M。雖然可以將其從系統表空間提出了，使系統表空間不再因為大事務而迅速不斷增大，但是獨立出來的undo表空間仍然比較雞肋，不能truncate。而且也沒有相關undo表空間文件大小的閾值。

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

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

被選中刪除的undo文件，對應的回滾段標記為inactive，purge回收不再使用的回滾段，完成后進行truncate，恢復到10M大小，回滾段再次標記為active。

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

undo tablesapce和回滾段之間什么關系

可以看到在系統啟動的時候創建好undo表空間。默認undo表空間放到系統表空間里面。當將undo表空間獨立出來時，undo表空間輪流分給各個回滾段。

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