MySQL MVCC機制

標籤：creating   技術   cell   val   from   欄位   https   ble   技術分享   

本文同時發表在https://github.com/zhangyachen/zhangyachen.github.io/issues/68

行結構

每一行額外包含三個隱藏欄位：

• DB_TRX_ID：事務ID。行的建立時間和刪除時間記錄的就是此值。
• DB_ROLL_PTR：指向目前記錄項的undo資訊。
• DB_ROW_ID:：隨著新行插入單調遞增的一個欄位。當由innodb自動產生叢集索引時，叢集索引包括這個DB_ROW_ID的值，不然的話叢集索引中不包括這個值。
• 在insert操作時，建立時間 = DB_ROW_ID，這時，“刪除時間 ”是未定義的。
• 在update操作時，複製新增行的“建立時間”=DB_ROW_ID，刪除時間未定義，舊資料行“建立時間”不變，刪除時間=該事務的DB_ROW_ID。
• 在delete操作時，相應資料行的“建立時間”不變，刪除時間 = 該事務的DB_ROW_ID。

• select操作對兩者都不修改，唯讀相應的資料。

  Read View

    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 */

關於low_limit_id，up_limit_id的理解：
up_limit_id：當前已經提交的事務號 + 1，事務號 < up_limit_id ，對於當前Read View都是可見的。理解起來就是建立Read View視圖的時候，之前已經提交的事務對於該事務肯定是可見的。
low_limit_id：當前最大的事務號 + 1，事務號 >= low_limit_id，對於當前Read View都是不可見的。理解起來就是在建立Read View視圖之後建立的事務對於該事務肯定是不可見的。

另外，trx_ids為活躍事務id列表，即Read View初始化時當前未提交的事務列表。所以當進行RR讀的時候，trx_ids中的事務對於本事務是不可見的（除了自身事務，自身事務對於表的修改對於自己當然是可見的）。理解起來就是建立RV時，將當前活躍事務ID記錄下來，後續即使他們提交對於本事務也是不可見的。

example

步驟	1	2	3
一	begin
二		begin
三	insert into test(score) values(1607); 假設此時事務號21
四		insert into test(score) values(1607); 此時事務號22
五	此時建立讀視圖，up_limit_id = 21， low_limit_id = 23 活躍事務列表為(21,22)
六			insert into test(score) values(1620); 事務號為23
七			insert into test(score) values(1621); 事務號為24
八			insert into test(score) values(1622); 事務號為25
九			select * from test; 此時的up_limit_id 為21，low_limit_id 為26，活躍事務列表為（21,22），故21，22在活躍事務列表不可見
十		select * from test; 此時low_limit_id為26，up_limit_id 為21，活躍事務列表是(21,22) 22本事務自身可見。21的在活躍事務列表不可見。23,24不在活躍事務列表，可見
十一	select * from test; 事務內readview不變，low_limit_id = 23，up_limit_id = 21，活躍事務列表 （21,22）。故21自身可見，22在活躍事務列表不可見。>=23的都不可見

注意的幾點：

• Read View視圖是在進行RR讀之前建立的，而不是在事務剛begin時建立的。如果Read View視圖是在事務剛begin時建立的，那麼在步驟四中事務22的Read View就定下來了（up_limit_id = 21，low_limit_id = 23），那麼在步驟十中就看不到3中提交的資料了，因為事務號23,24,25大於等於事務22.low_limit_id
• 事務內Read View一旦建立就不變化了。
• 在第十步中按我之前的理解，3中insert的資料是在2中begin之後插入的，按理說2是看不到3中insert插入的資料的。但是事務保證的是兩次select的資料是一致的，所以Read View是在第一次select時建立的，所以3中insert的資料是在2中可以看到。

參考資料：http://hedengcheng.com/?p=148

MySQL MVCC機制