在MySQL5.6中開始支持把undo log分離到獨立的表空間，並放到單獨的文件目錄下；這給咱們部署不一樣IO類型的文件位置帶來便利，對於併發寫入型負載，咱們能夠把undo文件部署到單獨的高速存儲設備上.html
1.使用
有幾個參數來控制該行爲
用於設定建立的undo表空間的個數，在Install db時初始化後，就不再能被改動了；
默認值爲0，表示不獨立設置undo的tablespace，默認記錄到ibdata中；不然，則在undo目錄下建立這麼多個undo文件，例如假定設置該值爲16，那麼就會建立命名爲undo001~undo016的undo tablespace文件，每一個文件的默認大小爲10M
修改該值可能會致使Innodb沒法完成初始化；
用於表示回滾段的個數（早期版本的命名爲
innodb_rollback_segments ），該變量能夠動態調整，可是物理上的回滾段不會減小，只是會控制用到的回滾段的個數;
默認爲128個回滾段
當開啓獨立undo表空間時，指定undo文件存放的目錄
若是咱們想轉移undo文件的位置，只須要修改下該配置，並將undo文件拷貝過去就能夠了。
2.相關代碼
#在innodb啓動時(innobase_start_or_create_for_mysql)，會進行undo表空間初始化，細節見函數srv_undo_tablespaces_init
–>若是是新建實例，會去建立undo log文件，undo表空間的space id從1開始；默認初始化大小爲10M，由宏SRV_UNDO_TABLESPACE_SIZE_IN_PAGES控制;
–>讀取當前實例的全部undo表空間的space id （trx_rseg_get_n_undo_tablespaces）
首先從ibdata中讀取到事務系統的文件頭，而後再從其中記錄的回滾段信息，找到回滾段對應的space id和page no（trx_sysf_rseg_get_space，trx_sysf_rseg_get_page_no），並按照space id排序後返回；
–>根據上一步讀到的space id依次打開undo文件(srv_undo_tablespace_open)，若是不存在，就標識啓動失敗
因此undo文件也是相似ibdata的重要文件，目前是不能夠刪除的。。。因此不要試圖刪除undo文件來釋放空間- -!
能夠容忍定義的table space個數比已有的undo文件個數要少(但全部的undo文件依然會打開)，反之則報錯初始化失敗
#undo回滾段初始化 （trx_sys_create_rsegs）
若是是正常shutdown重啓，而且設置的回滾段個數大於目前已經使用的回滾段個數(trx_sysf_rseg_find_free)，就會去新建回滾段(trx_rseg_create)
這裏老是從第一個undolog tablespace開始初始化回滾段，看起來彷佛有些問題，極端狀況下，若是我每次重啓遞增innodb_undo_logs，是否是意味着全部的undo回滾段都會寫入到第一個undo tablespace中?
完成初始化後，將當前可用的undo 回滾段的個數複製給srv_available_undo_logs，能夠經過show status查看：
root@performance_schema 12:16:18>show status like ‘Innodb_available_undo_logs';
+—————————-+——-+
| Variable_name | Value |
+—————————-+——-+
| Innodb_available_undo_logs | 128 |
+—————————-+——-+
1 row in set (0.00 sec)
啓動後，innodb_undo_logs是能夠動態調整的，但最大不能夠超過Innodb_available_undo_logs
#在一個非只讀的事務開啓時，會爲其分配回滾段(trx_assign_rseg_low)，動態的調整innodb_undo_logs能夠限定分配的回滾段範圍；
TODO
當有長時間運行的事務時，可能致使purge操做來不及回收undo空間，進而致使undo空間急劇膨脹；理論上講，若是作一次乾淨的shutdown，應該能夠安全的將將這些undo文件刪除並從新作一次初始化；也許將來的某個MySQL版本可能實現這個功能，這對於某些服務（好比按磁盤空間收費的雲計算提供商）是很是有必要的功能
轉載自Simple Lifemysql