mvcc (multiversion concurrency control)，即多版本併發控制技術,它使得大部分支援行鎖的事務引擎，不再單純的使用行鎖來進行資料庫的併發控制，取而代之的是把資料庫的行鎖與行的多個版本結合起來，只需要很小的開銷,就可以實現非鎖定讀，從而大大提高資料庫系統的併發效能
innodb：通過為每一行記錄新增兩個額外的隱藏的值來實現mvcc，這兩個值乙個記錄這行資料何時被建立，另外乙個記錄這行資料何時過期（或者被刪除）。但是innodb並不儲存這些事件發生時的實際時間，相反它只儲存這些事件發生時的系統版本號。這是乙個隨著事務的建立而不斷增長的數字。每個事務在事務開始時會記錄它自己的系統版本號。
每個查詢必須去檢查每行資料的版本號與事務的版本號是否相同。讓我們來看看當隔離級別是repeatable read時這種策略是如何應用到特定的操作的：select innodb必須每行資料來保證它符合兩個條件：
1、innodb必須找到乙個行的版本，它至少要和事務的版本一樣老(也即它的版本號不大於事務的版本號)。這保證了不管是事務開始之前，或者事務建立時，或者修改了這行資料的時候，這行資料是存在的。
2、這行資料的刪除版本必須是未定義的或者比事務版本要大。這可以保證在事務開始之前這行資料沒有被刪除。符合這兩個條件的行可能會被當作查詢結果而返回。
insert：innodb為這個新行記錄當前的系統版本號。
delete：innodb將當前的系統版本號設定為這一行的刪除id。
update：innodb會寫乙個這行資料的新拷貝，這個拷貝的版本為當前的系統版本號。它同時也會將這個版本號寫到舊行的刪除版本裡。
這種額外的記錄所帶來的結果就是對於大多數查詢來說根本就不需要獲得乙個鎖。他們只是簡單地以最快的速度來讀取資料，確保只選擇符合條件的行。這個方案的缺點在於儲存引擎必須為每一行儲存更多的資料，做更多的檢查工作，處理更多的善後操作。
mvcc只工作在repeatable read和read commited隔離級別下。read uncommited不是mvcc相容的，因為查詢不能找到適合他們事務版本的行版本；它們每次都只能讀到最新的版本。seriablable也不與 mvcc相容，因為讀操作會鎖定他們返回的每一行資料。
innodb mvcc主要是為repeatable-read事務隔離級別做的。在此隔離級別下，a、b客戶端所示的資料相互隔離，互相更新不可見
了解innodb的行結構、read-view的結構對於理解innodb mvcc的實現由重要意義
innodb儲存的最基本row中包含一些額外的儲存資訊 data_trx_id，data_roll_ptr，db_row_id，delete bit
具體的執行過程
begin->用排他鎖鎖定該行->記錄redo log->記錄undo log->修改當前行的值，寫事務編號，回滾指標指向undo log中的修改前的行
上述過程確切地說是描述了update的事務過程，其實undo log分insert和update undo log，因為insert時，原始的資料並不存在，所以回滾時把insert undo log丟棄即可，而update undo log則必須遵守上述過程
mysql資料庫 MVCC（多版本併發控制）（1）
在mysql 的眾多儲存引擎中，只有 innodb 支援事務，所有這裡說的事務隔離級別指的是 innodb 下的事務隔離級別。事務隔離級別，以及導致的問題 隔離級別 定義 髒讀 幻讀 不可重複度 讀未提交 乙個事務可以讀取到另乙個事務未提交的修改。這會帶來髒讀 幻讀 不可重複讀問題。讀已提交 乙個事...
mysql多版本併發控制MVCC
innodb的mvcc是通過在每行記錄的後面儲存兩個隱藏的列來實現的，這兩個列乙個儲存行的建立時間，乙個儲存行的過期時間。但是並不是儲存時間而是儲存版本號，每開始乙個新的事務，版本號會自動遞增。事務開始時刻的系統版本號會作為事務的版本號，用來和查詢到每行記錄的版本號進行比較。select innod...
mysql多版本併發控制MVCC
set global transaction isolation level read committed 全域性的 set session transaction isolation level read committed 當前會話 複製 set autocommit 1 自動提交，為0手動提交...