InnoDB多版本(MVCC)實現簡要分析
update non-primary key(diff value) 3
update non-primary key(same value) 4
基本知識
假設對於多版本(MVCC)的基礎知識，有所瞭解。InnoDB爲了實現多版本的一致讀，採用的是基於回滾段的協議。
行結構
InnoDB表數據的組織方式爲主鍵聚簇索引。由於採用索引組織表結構，記錄的ROWID是可變的(索引頁分裂的時候，Structure Modification Operation，SMO)，因此二級索引中採用的是(索引鍵值, 主鍵鍵值)的組合來唯一確定一條記錄。
無論是聚簇索引，還是二級索引，其每條記錄都包含了一個DELETED BIT位，用於標識該記錄是否是刪除記錄。除此之外，聚簇索引記錄還有兩個系統列：DATA_TRX_ID，DATA_ROLL_PTR。DATA _TRX_ID表示產生當前記錄項的事務ID；DATA _ROLL_PTR指向當前記錄項的undo信息。
聚簇索引行結構(與多版本一致讀有關的部分，DELETED BIT省略)：
二級索引行結構：
從聚簇索引行結構，與二級索引行結構可以看出，聚簇索引中包含版本信息(事務號+回滾指針)，二級索引不包含版本信息，二級索引項的可見性如何判斷？下面將會給出。
Read View
InnoDB默認的隔離級別爲Repeatable Read (RR)，可重複讀。InnoDB在開始一個RR讀之前，會創建一個Read View。Read View用於判斷一條記錄的可見性。Read View定義在read0read.h文件中，其中最主要的與可見性相關的屬性如下：
dulint low_limit_id; /* 事務號 >= low_limit_id的記錄，對於當前Read
View都是不可見的 */
dulint up_limit_id; /* 事務號 < up_limit_id ，對於當前Read View都是可見的 */
ulint n_trx_ids; /* Number of cells in the trx_ids array */
dulint* trx_ids; /* Additional trx ids which the read should
not see: typically, these are the active
transactions at the time when the read is
serialized, except the reading transaction
itself; the trx ids in this array are in a
descending order */
dulint creator_trx_id; /* trx id of creating transaction, or
(0, 0) used in purge */
簡單來說，Read View記錄讀開始時，所有的活動事務，這些事務所做的修改對於Read View是不可見的。除此之外，所有其他的小於創建Read View的事務號的所有記錄均可見。可見包括兩層含義：
-
記錄可見，且Deleted bit = 0；當前記錄是可見的有效記錄。
-
記錄可見，且Deleted bit = 1；當前記錄是可見的刪除記錄。此記錄在本事務開始之前，已經刪除。
測試方法：
–create table and index
create table test (id int primary key, comment char(50)) engine=InnoDB;
create index test_idx on test(comment);
–Insert
insert into test values(1, ‘aaa’);
insert into test values(2, ‘bbb’);
–update primary key
update test set id = 9 where id = 1;
–update non-primary key with different value
update test set comment = ‘ccc’ where id = 9;
–update non-primary key with same value
update test set comment = ‘bbb’ where id = 2 and comment = ‘bbb’;
–read隔離級別
repeatable read（RR）
測試結果
update primary key
代碼調用流程：
ha_innobase::update_row -> row_update_for_mysql -> row_upd_step -> row_upd -> row_upd_clust_step -> row_upd_clust_rec_by_insert -> btr_cur_del_mark_set_clust_rec -> row_ins_index_entry
簡單來說，就是將cluster index的舊記錄標記位刪除；插入一條新紀錄。該語句執行完之後，數據結構如下：
老版本仍舊存儲在聚簇索引之中，其DATA_TRX_ID被設置爲1811，Deleted bit設置爲1，undo中記錄了前鏡像的事務id = 1809。新版本DATA_TRX_ID也爲1811。通過此圖，還可以發現，雖然新老版本是一條記錄，但是在聚簇索引中是通過兩條記錄來標識的。同時，由於更新了主鍵，二級索引也需要做相應的更新(二級索引中包含主鍵項)。
update non-primary key(diff value)
更新comment字段，代碼調用流程與上面有部分不同，可以自行跟蹤，此處省略。更新操作執行完之後，索引結構變更如下：
從上圖可見，更新二級索引的鍵值時，聚簇索引本身並不會產生新的記錄項，而是將舊版本信息記錄在undo之中。與此同時，二級索引將會產生新的索引項，其PK值保持不變，指向聚簇索引的同一條記錄。細心的讀者可能會發現，二級索引頁面中有一個MAX_TRX_ID，此值記錄的是更新二級索引頁面的最大事務ID。通過MAX_TRX_ID的過濾，INNODB能夠實現大部分的輔助索引覆蓋性掃描(僅僅掃描輔助索引，不需要回聚簇索引)。具體過濾方法，將在後面的內容中給出。
update non-primary key(same value)
最後一個測試用例，是更新comment項爲同樣的值。在我的測試中，更新之後的索引結構如下：
聚簇索引仍舊會更新，但是二級索引保持不變。
總結
-
無論是聚簇索引，還是二級索引，只要其鍵值更新，就會產生新版本。將老版本數據deleted bti設置爲1；同時插入新版本。
-
對於聚簇索引，如果更新操作沒有更新primary key，那麼更新不會產生新版本，而是在原有版本上進行更新，老版本進入undo表空間，通過記錄上的undo指針進行回滾。
-
對於二級索引，如果更新操作沒有更新其鍵值，那麼二級索引記錄保持不變。
-
對於二級索引，更新操作無論更新primary key，或者是二級索引鍵值，都會導致二級索引產生新版本數據。
-
聚簇索引設置記錄deleted bit時，會同時更新DATA_TRX_ID列。老版本DATA_TRX_ID進入undo表空間；二級索引設置deleted bit時，不寫入undo。
可見性判斷
主鍵查找
select * from test where id = 1;
-
針對測試1，如果1811(DATA_TRX_ID) < read_view.up_limit_id，證明被標記爲刪除的記錄1可見。刪除可見 -> 無記錄返回。
-
針對測試1，如果1811(DATA_TRX_ID) >= read_view.low_limit_id，證明被標記爲刪除的記錄1不可見，通過DATA_ROLL_PTR回滾記錄，得到DATA_TRX_ID = 1809。如果1809可見，則返回記錄(1，aaa)；否則無記錄返回。
-
針對測試1，如果up_limit_id，low_limit_id都無法判斷可見性，那麼遍歷read_view中的trx_ids，依次對比事務id，如果在DATA_TRX_ID在trx_ids數組中，則不可見(更新未提交)。
select * from test where id = 9;
-
針對測試2，如果1816可見，返回(9,ccc)。
-
針對測試2，如果1816不可見，通過DATA_ROLL_PTR回滾到1811，如果1811可見，返回(9, aaa)。
-
針對測試2，如果1811不可見，無結果返回。
select * from test where id > 0;
-
針對測試1，索引中，滿足條件的同一記錄，有兩個版本(版本1，delete bit =1)。那麼是否會一條記錄返回兩次呢？必定不會，這是因爲pk = 1的可見性與pk = 9的可見性是一致的，同時pk = 1是標記了deleted bit的版本。如果事務ID = 1811可見。那麼pk = 1 delete可見，無記錄返回，pk = 9返回記錄；如果1811不可見，回滾到1809可見，那麼pk = 1返回記錄，pk = 9回滾後無記錄。
總結：
-
通過主鍵查找記錄，需要配合read_view，記錄DATA_TRX_ID，記錄DATA_ROLL_PTR指針共同判斷。
-
read_view用於判斷當前記錄是否可見(判斷DATA_TRX_ID)。DATA_ROLL_PTR用於將當前記錄回滾到前一版本。
非主鍵查找
select comment from test where comment > ‘ ‘;
-
針對測試2，二級索引，當前頁面的最大更新事務MAX_TRX_ID = 1816。如果MAX_TRX_ID < read_view.up_limit_id，當前頁面所有數據均可見，本頁面可以進行索引覆蓋性掃描。丟棄所有deleted bit = 1的記錄，返回deleted bit = 0 的記錄；此時返回 (ccc)。(row_select_for_mysql ->lock_sec_rec_cons_read_sees)
-
針對測試2，二級索引，如果當前頁面不能滿足MAX_TRX_ID < read_view.up_limit_id，說明當前頁面無法進行索引覆蓋性掃描，此時需要針對每一項，到聚簇索引中判斷可見性。回到測試2，二級索引中有兩項pk = 9 (一項deleted bit = 1，另一個爲0)，對應的聚簇索引中只有一項pk= 9。如何保證通過二級索引過來的同一記錄的多個版本，在聚簇索引中最多隻能被返回一次？如果當前事務id 1811可見。二級索引pk = 9的記錄(兩項)，通過聚簇索引的undo，都定位到了同一記錄項。此時，InnoDB通過以下的一個表達式，來保證來自二級索引，指向同一聚簇索引記錄的多個版本項，有且最多僅有一個版本將會返回數據：
if (clust_rec
&& (old_vers || rec_get_deleted_flag(
rec,dict_table_is_comp(sec_index->table)))
&& !row_sel_sec_rec_is_for_clust_rec(rec, sec_index, clust_rec, clust_index))
滿足if判斷的所有聚簇索引記錄，都直接丟棄，以上判斷的邏輯如下：
-
需要回聚簇索引掃描，並且獲得記錄
-
聚簇索引記錄爲回滾版本，或者二級索引中的記錄爲刪除版本
-
聚簇索引項，與二級索引項，其鍵值並不相等
爲什麼滿足if判斷，就可以直接丟棄數據？用白話來說，就是我們通過二級索引記錄，定位聚簇索引記錄，定位之後，還需要再次檢查聚簇索引記錄是否仍舊是我在二級索引中看到的記錄。如果不是，則直接丟棄；如果是，則返回。
根據此條件，結合查詢與測試2中的索引結構。可見版本爲事務1811.二級索引中的兩項pk = 9都能通過聚簇索引回滾到1811版本。但是，二級索引記錄(ccc,9)與聚簇索引回滾後的版本(aaa,9)不一致，直接丟棄。只有二級索引記錄(aaa,9)保持一致，直接返回。
總結：
-
二級索引的多版本可見性判斷，需要通過聚簇索引完成。
-
二級索引頁面中保存了MAX_TRX_ID，可以快速判斷當前頁面中，是否所有項均可見，可以實現二級索引頁面級別的索引覆蓋掃描。一般而言，此判斷是滿足條件的，保證了索引覆蓋掃描 (index only scan)的高效性。
-
二級索引中的項，需要與聚簇索引中的可見性進行比較，保證聚簇索引中的可見項，與二級索引中的項數據一致。
疑問
-
在http://blogs.InnoDB.com/wp/2011/04/mysql-5-6-multi-threaded-purge/中，作者提到，InnoDB的purge操作，是通過遍歷undo來實現對於標記位deleted項的回收的。如果二級索引本身標記deleted位不記錄undo，那麼這個回收操作如何完成？還是說purge是通過解析redo來完成回收的？（根據下面對於purge的流程分析，此問題已解決）
Purge流程
Purge功能：
InnoDB由於要支持多版本協議，因此無論是更新，刪除，都只是設置記錄上的deleted bit標記位，而不是真正的刪除記錄。後續這些記錄的真正刪除，是通過Purge後臺進程實現的。Purge進程定期掃描InnoDB的undo，按照先讀老undo，再讀新undo的順序，讀取每條undo record。對於每一條undo record，判斷其對應的記錄是否可以被purge(purge進程有自己的read view，等同於進程開始時最老的活動事務之前的view，保證purge的數據，一定是不可見數據，對任何人來說)，如果可以purge，則構造完整記錄(row_purge_parse_undo_rec)。然後按照先purge二級索引，最後purge聚簇索引的順序，purge一個操作生成的舊版本完整記錄。
一個完整的purge函數調用流程如下：
row_purge_step->row_purge->trx_purge_fetch_next_rec->row_purge_parse_undo_rec
->row_purge_del_mark->row_purge_remove_sec_if_poss
->row_purge_remove_clust_if_poss
總結：
-
purge是通過遍歷undo實現的。
-
purge的粒度是一條記錄上的一個操作。如果一條記錄被update了3次，產生3個old版本，均可purge。那麼purge讀取undo，對於每一個操作，都會調用一次purge。一個purge刪除一個操作產生的old版本(按照操作從老到新的順序)。
-
purge按照先二級索引，最後聚簇索引的順序進行。
-
purge二級索引，通過構造出的索引項進行查找定位。不能直接針對某個二級頁面進行，因爲不知道記錄的存放page。
-
對於二級索引設置deleted bit爲不需要記錄undo，因爲purge是根據聚簇索引undo實現。因此二級索引deleted bit被設置爲1的項，沒有記錄undo，仍舊可以被purge。
-
purge是一個耗時的操作。二級索引的purge，需要search_path定位數據，相當於每個二級索引，都做了一次index unique scan。
-
一次delete操作，IO翻番。第一次IO是將記錄的deleted bit設置爲1；第二次的IO是將記錄刪除。
