我們建立乙個hero表：
create table hero (
number int,
name varchar(100),
country varchar(100),
primary key (number)
) engine=innodb charset=utf8;
然後向這個表裡插入一條資料：
insert into hero values(1, 『劉備』, 『蜀』);
現在表裡的資料就是這樣的：
對於使用innodb儲存引擎的表來說，它的聚簇索引記錄中除了包含使用者定義的列外，還包含兩個必要的隱藏列：
假設插入該記錄的事務id為80，那麼此刻該條記錄的示意圖如下所示：
假設之後兩個事務id分別為100、200的事務對這條記錄進行update操作，操作流程如下：
每次對記錄進行改動，都會記錄一條undo日誌，每條undo日誌也都有乙個roll_pointer屬性，可以將這些undo日誌都連起來，串成乙個鍊錶，所以現在的情況就像下圖一樣：
對該記錄每次更新後，都會將舊值放到一條undo日誌中，就算是該記錄的乙個舊版本，隨著更新次數的增多，所有的版本都會被roll_pointer屬性連線成乙個鍊錶，我們把這個鍊錶稱之為版本鏈，版本鏈的頭節點就是當前記錄最新的值。另外，每個版本中還包含生成該版本時對應的事務id。
版本鏈中存放了該記錄各個時間段的歷史資料，而對於不同隔離級別的事務來說，版本鏈中的資料對它們的可見性是不同的，即它們需要讀取的資料版本不同。
read committed和repeatable read隔離級別的區別在於：
假設初始時資料表的資料為：
如下圖，事務trx1和事務trx2為活動事務，正在執行。
對於不同隔離級別的事務，它們是如何來判斷自己應該讀取資料的版本呢？為此，設計innodb的大叔提出了乙個readview的概念，這個readview中主要包含4個比較重要的內容：
有了這個readview，事務在訪問某條記錄時，只需要按照下邊的步驟，就可以判斷記錄的某個版本是否可見：
如果某個版本的資料對當前事務不可見的話，那就順著版本鏈找到下乙個版本的資料，繼續按照上邊的步驟判斷可見性，依此類推，直到版本鏈中的最後乙個版本。如果最後乙個版本也不可見的話，那麼就意味著該條記錄對該事務完全不可見，查詢結果就不包含該記錄。
由上面介紹的read committed和repeatable read隔離級別的區別可知，在mysql中，read committed和repeatable read隔離級別的的乙個非常大的本質區別就是它們生成readview的時機不同。
從上邊的描述中我們可以看出來，所謂的mvcc（multi-version concurrency control ，多版本併發控制）指的就是在使用read committd、repeatable read這兩種隔離級別的事務在執行普通的seelct操作時訪問記錄的版本鏈的過程，這樣子可以使不同事務的讀-寫、寫-讀操作併發執行，從而提公升系統效能。read committd、repeatable read這兩個隔離級別的乙個很大不同就是：生成readview的時機不同，read committd在每一次進行普通select操作前都會生成乙個readview，而repeatable read只在第一次進行普通select操作前生成乙個readview，之後的查詢操作都重複使用這個readview就好了。
MYSQL MVCC多版本併發控制
innodb使用mvcc實現高併發 mvcc並不是mysql獨有的，oracle，postgresql等都實現了mvcc,但各自實現機制不同。因為mvcc沒有統一實現標準。mvcc可以認為它是行級鎖的乙個變種，但是它在很多情況下避免了加鎖操作，因此開銷更低。實現了非阻塞的讀操作，寫操作也只鎖定必要的...
mysql MVCC 多版本併發控制
mvcc是行級鎖的乙個變種，但是它在很多情況下避免了加鎖操作，因此開銷更低。大多數的mvcc都實現了非阻塞的讀操作，寫操作也只鎖定必要的行。主要是避免讀寫場景下加鎖控制的效能開銷。multiversion concurrency control 多版本併發控制 併發訪問 讀或者寫 資料庫時，對正在事...
mysql mvcc多版本併發控制
事務隔離的實現方案有兩種，lbcc和mvcc 基於鎖的併發控制，英文全稱lock based concurrent control。這種方案比較簡單粗暴，就是乙個事務去讀取一條資料的時候，就上鎖，不允許其他事務來操作 當然這個鎖的實現也比較重要，如果我們只鎖定當前一條資料依然無法解決幻讀問題 這個概...