前言
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 獨立表空間中。