MVCC：多版本併發控制（MVCC,Multiversion Currency Control）。通常狀況下，事務性儲存引擎不是隻使用表鎖，行加鎖的處理數據，而是結合了MVCC機制，以處理更多的併發問題。Mvcc處理高併發能力最強，
但系統開銷 比最大（較表鎖、行級鎖），這是最求高併發付出的代價。css
** InnoDB實現MVCC的方法是，它存儲了每一行的三個額外的隱藏字段:**html
1.DB_TRX_ID：一個6byte的標識，每處理一個事務，其值自動+1
#下面提到的「建立時間」和「刪除時間」記錄的就是這個DB_TRX_ID的值 #如insert、update、delete操做時，刪除操做用1個bit表示。 #DB_TRX_ID是最重要的一個，能夠經過語句「show engine innodb status」來查找 2.DB_ROLL_PTR: 大小是7byte,指向寫到rollback segment（回滾段）的一條undo log記錄 （update操做的話，記錄update前的ROW值） 3.DB_ROW_ID: 大小是6byte,該值隨新行插入單調增長。 #當由innodb自動產生彙集索引時彙集索引(即沒有主鍵時,由於MYSQL默認聚簇表,會自動生成一個ROWID) #包括這個DB_ROW_ID的值， #否則的話彙集索引中不包括這個值,這個用於索引當中。
DB_TRX_ID記錄了行的建立的時間刪除的時間在每一個事件發生的時候，每行存儲版本號，而不是存儲事件實際發生的時間。每次事物的開始這個版本號都會增長。自記錄時間開始，每一個事物都會保存記錄的系統版本號。
依照事物的版原本檢查每行的版本號。在insert操做時 「建立時間」=DB_TRX_ID，這時，「刪除時間」是未定義的；在update時，複製新增行的「建立時間」=DB_TRX_ID，刪除時間未定義，舊數據行「建立時間」不變，
刪除時間=該事務DB_TRX_ID；delete操做，相應數據行的「建立時間」不變，刪除時間=該事務的DB_ROW_ID；select操做對二者都不修改，只讀相應的數據shell
MVCC結合隔離級別:數據庫
1.READ UNCOMMITTED ，不適用MVCC讀，能夠讀到其餘事務修改甚至未提交的 2.READ COMMITTED ，其餘事務對數據庫的修改,只要已經提交,其修改的結果就是可見的, 與這兩個事務開始的前後順序無關，不徹底適用於MVCC讀， 3.REPEATABLE READ，可重複讀，徹底適用MVCC，只能讀取在它開始以前已經提交的事務對數據庫的修改, 在它開始之後,全部其餘事務對數據庫的修改對它來講均不可見 4.SERIALIZABLE ，徹底不適合適用MVCC，這樣全部的query都會加鎖，再它以後的事務都要等待
MVCC只工做在REPEATABLE READ和READ COMMITED隔離級別下bash
2 REPEATABLE READ 可重複讀下的MVCC
##### SELECTmarkdown
Innodb檢查沒行數據，確保他們符合兩個標準： 1.InnoDB只查找版本早於當前事務版本的數據行（也就是數據行的版本必須小於等於事務的版本），這確保當前事務 讀取的行都是事務以前已經存在的，或者是由當前事務建立或修改的行 2.行的刪除操做的版本必定是未定義的或者大於當前事務的版本號。肯定了當前事務開始以前，行沒有被刪除 符合了以上兩點則返回查詢結果。
INSERT
InnoDB爲每一個新增行記錄當前系統版本號做爲建立ID。
DELETE
InnoDB爲每一個刪除行的記錄當前系統版本號做爲行的刪除ID。
UPDATE
InnoDB複製了一行。這個新行的版本號使用了系統版本號。它也把系統版本號做爲了刪除行的版本。
3 MVCC深刻
若是根據事務DB_TRX_ID去比較獲取事務的話，按道理在一個事務B（在事務A後，但A還沒commit）select的話 B.DB_TRX_ID>A.DB_TRX_ID則應該能返回A事務對數據的操做以及修改。那不是和前面矛盾？其實否則。併發
InnoDB每一個事務在開始的時候，會將當前系統中的活躍事務列表（trx_sys->trx_list）建立一個副本（read view），而後一致性讀去比較記錄的tx id的時候，並非根據當前事務的tx id，而是根據read view最先一個事務的tx id（read view->up_limit_id）來作比較的，這樣就能確保在事務B以前沒有提交的全部事務的變動，B事務都是看不到的。固然，這裏還有個小問題要處理一下，就是當前事務自身的變動仍是須要看到的。mvc