深入淺出INNODB MVCC機制與原理

1、摘要：1、基礎(chǔ)知識2、MVCC 實現(xiàn)原理以及視圖化理解（包含些測試以便理解）3、深 MVCC 實現(xiàn)機制一、基礎(chǔ)知識事務(wù)：事務(wù)是一組原子性sql mysql 對改事務(wù)單元內(nèi)的所sql sql 語句才對數(shù)據(jù)生效，若sql 中任意不能執(zhí)行或出錯則事務(wù)操作失敗，所有對數(shù)據(jù)的操作則無效（數(shù)據(jù)。事務(wù)有四個屬性：1、原子性：事務(wù)被認為不可分的一個工作單元，要么全部正常執(zhí)行，要么全部不執(zhí)行。2、一致性：事務(wù)操作對數(shù)據(jù)庫總是從一種一致性的狀態(tài)轉(zhuǎn)換成另外一種一致性狀態(tài)。3、隔離性：一個事務(wù)的操作結(jié)果在內(nèi)部一致，可見，而對除自己以外的事務(wù)是不可見的。4、永久性：事務(wù)在未提交前數(shù)據(jù)一般情況下可以回滾恢復數(shù)據(jù)，一旦提交

2、）數(shù)據(jù)的改變則變成永久（當然用update 肯定還能修改。ps:MYSAM （INNODB 、讀鎖：也叫共享鎖、S 鎖，若事務(wù)T 對數(shù)據(jù)對象A 加上S 鎖，則事務(wù)T 可以讀A 但不能修改A，其他事務(wù)只能再對A 加 S 鎖，而不能加X 鎖，直到T 釋放A 上的S 鎖。這保證了其他事務(wù)可以讀，但在T 釋放A 上的S 鎖之前不能對A 寫鎖：又稱排他鎖、X 鎖。若事務(wù)T 對數(shù)據(jù)對象A 加上X 鎖，事務(wù) T 可以讀A 也可以修改A，其他事務(wù)不能再對A 加任何鎖，直到T 釋放A 上的鎖。這保證了其他事務(wù)在T 釋放A上的鎖之前不能再讀取和修改A。表鎖：l大多數(shù)鎖策略都支持（常見mysql ，是系統(tǒng)開銷最低但

3、并發(fā)性最低的一個鎖策略。事務(wù)t 對整個表加讀鎖，則其他事務(wù)可讀不可寫，若加寫鎖，則其他事務(wù)增刪改都不行。行級鎖：操作對象是數(shù)據(jù)表中的一行。是 MVCC 技術(shù)用的比較多的，但在MYISAM 用不了，行級鎖用mysql 的儲存引擎實現(xiàn)而不是mysql 大，處理高并發(fā)較好。多版本并發(fā)控制l。一般情況下，事MVCC 機制，以處理c 處理高并發(fā)能力最強，但系統(tǒng)開銷比最大（這是最求高并發(fā)付出的代價。Autocommit：是 mysql 一個系統(tǒng)變量，默認情況下autocommit=1表示 mysql 把沒一條sql 語句自動的提交，而不commit 語句。所以，當要開啟事務(wù)操作時要把autocommit

4、設(shè)0，可以通過”來設(shè)置二、MVCC實現(xiàn)原理以及例化理解（包含些測試以便理解）第一：先mysql 第二版（中文版也、加粗標志出來，且給出測試證明。 Ps：這些只是外部看來的理解層面，深層次在第三點講解-InnoDB 實現(xiàn) MVCC 的方法是，它存儲了每一行的兩個(1)額外的隱藏字段，這兩個隱時間開始，每個事物都會保存記錄的系統(tǒng)版本號。依照事物的版本來檢查每行的版本號。在事物隔離級別為可重復讀的情況下，來看看怎樣應(yīng)用它。SELECTInnodb 檢查沒行數(shù)據(jù)，確保他們符合兩個標準：1、InnoDB 只查找版本早于當前事務(wù)版本的數(shù)據(jù)行（也就是數(shù)據(jù)行的版本必須小于等于事務(wù)的版本，這確保當前事務(wù)讀取的行

5、都是事務(wù)之前已經(jīng)存在的是由當前事務(wù)創(chuàng)建或修改的行2被刪除(2)符合了以上兩點則返回查詢結(jié)果。INSERTInnoDB 為每個新增行記錄當前系統(tǒng)版本號作為創(chuàng)建ID。DELETEInnoDB 為每個刪除行的記錄當前系統(tǒng)版本號作為行的刪除ID。UPDATEInnoDB 作為了刪除行的版本。-不是兩個，是三個。6byte DB_TRX_ID 的值，如 insert、delete bit 表示。 DB_TRX_ID 語句“showengineinnodbstatus”來查找，如下：-TRANSACTIONS-Trxidcounter0430621 Purgedonefortrxsn:o0430136un

6、don:oA.DB_TRX_ID DB_TRX_ID 的值是系統(tǒng)版本號的值，系統(tǒng)版本號是自動增加的，所以DB_TRX_ID A 事務(wù)開始后B 事務(wù)開始前有一個t 操作插入一行數(shù)據(jù)（沒有、，B.DB_TRX_ID=A.DB_TRX_ID+1+1 1，其實并不矛盾，其實每一條 sql 操作可以當作一個事務(wù)，因為insert 操作是一個事務(wù)，A 事務(wù)之后新增2個事務(wù)， 所以是加2而不是1。2例化test 數(shù)據(jù)trx 代表改行數(shù)據(jù)是那個事務(wù)創(chuàng)建creat_num 是“創(chuàng)建時間”，也就是DB_TRX_ID 值dele_num id 為2 的數(shù)據(jù)行的C“刪除”了改行。B事務(wù)有; 語句按照C原理該語句相當于

7、wherecreat_num=2011and(dele_num=NULLORdele_num2011),所以返數(shù)據(jù)是id為12行。D事務(wù)select*fromtest;則返回出id2的行。因2行被C事務(wù)刪除了。例化2：UPDATEA 事務(wù)一條語句 。則先復制一條數(shù)據(jù)如藍色框（然后把舊行數(shù)據(jù)的設(shè)commit 后則刪除舊數(shù)據(jù)行例化3：DELET刪除就是設(shè)dele_num= DB_TRX_ID-于加上和一位淘寶網(wǎng)友討論一個問題（關(guān)于事務(wù)隔離級別，這里就直接貼不整理了）網(wǎng)友：請教個問題b的事務(wù)一定是按D 順序提交么？D 為的一定在0的事務(wù)之后？筆者：這個問題我也不確定。我認為不是按順序的可以這樣想一下

8、，加a 事務(wù)很大是，然后還沒t之前有d為的事務(wù)b 并發(fā)開始處理，但b事務(wù)很小處理完了，如果要等a 事務(wù)的話則是一個雞肋了當然還有考慮鎖的問題，如a 事務(wù)設(shè)置了排他鎖且b事務(wù)有寫操作那不事務(wù)則在等待隊列中了，t的順序肯定 a 然后b 的！網(wǎng)友如果是這樣的話假設(shè)三個事務(wù)最先提交了這時新事，應(yīng)該能看的更改，而如果按當前活躍D 的最小的比較（這時0，那就看不的更新。筆者：結(jié)合事務(wù)隔離級別：1D D 不適用C讀可以讀到其他事務(wù)修改甚至未提交的D D ，其他事務(wù)對數(shù)據(jù)庫的修只要已經(jīng)提其修改的結(jié)果就是可見的與這兩個事務(wù)開始的先后順序無關(guān)，不完全適用C讀，像你說0的的是可以（按照C理論應(yīng)該不行的但適2（能MV

9、CC 理論。REPEATABLE ,見4、 SERIALIZABLE ，完全不適合適用，這樣所有的query 都會加鎖，再它之后的事務(wù)都要等待MVCC 只工作在REPEATABLE READ和 READ COMMITED隔離級別下-于加上MVCC 實現(xiàn)機制1creat_num DB_TRX_ID 去比較獲取事務(wù)的話，按道理在一個事務(wù) 比 A 后，但 A 還沒 commit）select 的話 B.DB_TRX_IDA.DB_TRX_ID 則應(yīng)該能返回A 事務(wù)對數(shù)據(jù)的操作以及修改。那不是和前面矛盾？其實不然，只是前面沒有講到以下內(nèi)容。B每個事務(wù)在開始的時候，會將當前系統(tǒng)中的活躍事務(wù)列表）創(chuàng)建一個

10、副本w，然后一致性讀去比較記錄的d的時候，并不是根據(jù)當txid readview 最早一個事務(wù)的txid（readview-up_limit_id）B 事務(wù)都是看不到的。當然，這里還有個小問題要處理一下，就是當前事務(wù)自身的變更還是需要看到的。在storage/innobase/read/read0read.c 中 實 現(xiàn) 了創(chuàng)建readview的 函數(shù)中實現(xiàn)了判斷一致性讀是否可見的read_view_sees_trx_id代碼：read_view_t* read_view_open_now(/*=*/trx_id_tcr_trx_id,/*!in:trx_idofcreating mem_he

11、ap_t*heap)/*!trx_list),heap);view-creator_trx_id=cr_trx_id;view-type=VIEW_NORMAL;view-undo_no=0;/*Nofuturetransactionsshouldbevisibleintheview*/ view-low_limit_no=trx_sys-max_trx_id;view-low_limit_id=view-low_limit_no;n=0;trx=UT_LIST_GET_FIRST(trx_sys-trx_list);/*Noactivetransactionshouldbevisible,e

12、xceptcr_trx*/while(trx)if(trx-id!=cr_trx_id&(trx-conc_state=TRX_ACTIVE|trx-conc_state=TRX_PREPARED)read_view_set_nth_trx_id(view,n,trx-id);n+;/*NOTEthatatransactionwhosetrxnumberismax_trx_idcanstillbeactive,ifitisinthemiddleofitscommit!Notethatwhenatransactionstarts,weinitializetrx-notoIB_ULONGLONG_

13、MAX.*/if(view-low_limit_notrx-no)view-low_limit_no=trx-no;trx=UT_LIST_GET_NEXT(trx_list,trx);view-n_trx_ids=n;if(n0)/*Thelastactivetransactionhasthesmallestid:*/view-up_limit_id=read_view_get_nth_trx_id(view ,n-1); elseview-up_limit_id=view-low_limit_id;UT_LIST_ADD_FIRST(view_list,trx_sys-view_list,

14、view);return(view);2、MVCC 如何控制update 操作前面說先復制新數(shù)據(jù)，并插入DB_TRX_ID DB_TRX_ID 現(xiàn)在先介紹幾個概念：DB_ROLL_PTR7byte 回滾指針。redo log：重做日志，就是每次mysql 在執(zhí)行寫入數(shù)據(jù)前先把要寫的信息保存在重寫redo_log 中的信息重新寫入數(shù)據(jù)。undolog ：撤銷日志，與redolog 恰恰相反，當一些更改在執(zhí)行一半時，發(fā)生意外， 而無法完成，則可以根據(jù)撤消日志恢復到更改之前的壯態(tài)。mvcc 中 update 步驟：1、記錄事務(wù)中修改行數(shù)據(jù)的相應(yīng)字段和（包括舊版本事務(wù)undo-log 中記錄。2、 修

15、改相應(yīng)數(shù)據(jù)。3、 在 redo-log 中保存要修改的相應(yīng)（新版本事務(wù)id）數(shù)據(jù)寫入以上驟詳細代碼內(nèi)容可看： HYPERLINK /gao1738/blog/item/dcec39d6185af2049d163d8c.html /gao1738/blog/item/dcec39d6185af2049d163d8c.html4update 不能正常運行怎根據(jù)undo-logredo-log 來回復5、當然如果當前版本事務(wù)沒有commit 的話則通過 undo-log 信息恢復原始數(shù)據(jù)狀態(tài)終于寫完了， 筆者用了一個多星期， 若有什么紕漏的地方， 請多多指教！ HYPERLINK mailto:445235728 445235728（benwin）參考文獻：mysql 第二版（中文版