mvcc多版本併發控制機制
上節我們說到了事務的acid特性和四種隔離級別，其中在可重複讀級別下是如何保證事務較高的隔離性的？靠mvcc(multi-version concurrency control)機制來保證的。mysql在讀已提交和可重複讀隔離級別下都實現了mvcc機制。
undo日誌版本鏈與read view機制
undo日誌版本鏈是指一行資料被多個事務依次修改過後，在每個事務修改完後，mysql會保留修改前的資料undo回滾日誌，並且用兩個隱藏欄位trx_id和roll_pointer把這些undo日誌串聯起來形成乙個歷史記錄版本鏈。
比如說我修改了一條資料，那這條修改前的資料是不是就消失了呢？不，它在我們undo回滾日誌裡。
下面請看圖：
read-view機制：在可重複讀隔離級別，當事務開啟，執行任何查詢sql時會生成當前事務的一致性檢視read-view，該檢視在事務結束之前都不會變化(如果是讀已提交隔離級別在每次執行查詢sql時都會重新生成)，這個檢視由執行查詢時所有未提交事務id陣列（陣列裡最小的id為min_id）和已建立的最大事務id（max_id）組成，事務裡的任何sql查詢結果需要從對應 版本鏈裡的最新資料開始逐條跟read-view做比對從而得到最終的快照結果。
注意：begin/start transaction 命令並不是乙個事務的起點，在執行到它們之後的第乙個修改操作innodb表的語句，事務才真正啟動，才會向mysql申請事務id，mysql內部是嚴格按照事務的啟動順序來分配事務id的。
版本鏈比對規則：
如果trx_id如果trx_id>max_id ，表示這個版本是由將來啟動的事務生成的，是肯定不可見的；
如果min_id <=trx_id<= max_id，那就包括兩種情況
a. 若 row 的 trx_id 在檢視陣列中，表示這個版本是由還沒提交的事務生成的，不可見，當前自己的事務是可見的；
b. 若 row 的 trx_id 不在檢視陣列中，表示這個版本是已經提交了的事務生成的，可見。
上圖中總共有3個事務，假如trx_id為103的事務已提交，101和102的事務為未提交，
我現在開啟乙個事務，做查詢：select name from student where id = 1;則read-view:[101,102],103;
name會是多少呢？mysql會先去undo版本鏈中拿到最新的trx_id（102），然後與read-view做比對，102在read-view陣列[101,102]中,滿足a，不可見；繼續從undo版本鏈中取trx_id(101),同樣與read-view做比對，不可見；繼續繼續從undo版本鏈中取trx_id（103）,比對，可見，所以結果為limin1。
結論：mvcc機制的實現就是通過read-view機制與undo版本鏈比對機制，使得不同的事務會根據資料版本鏈對比規則讀取 同一條資料在版本鏈上的不同版本資料。
MVCC多版本併發控制機制
1.1 什麼是mvcc mvcc multi version concurrency control 是一種多版本併發控制機制。與隔離級別緊密聯絡的另外乙個東西是併發排程，通過併發排程實現隔離級別。對於併發排程，不同的資料庫廠商有不同的實現機制，但基本原理類似，都是通過加鎖來保護資料物件不同時被多個...
多版本併發控制（MVCC）
mysql的大多數事務性儲存引擎 如innodb 實現的都不是簡單的行級鎖。基於提公升併發效能的考慮，它們一般都同時實現了多版本併發控制 mvcc 可以認為mvcc是行級鎖的乙個變種，但是它在很多情況下避免了加鎖操作，因此開銷更低。雖然實現機制有所不同，但大都實現了非阻塞的讀操作，寫操作也只鎖定必要...
多版本併發控制MVCC
大多數mysql的事務性儲存引擎，例如innodb.falcon 和pbxt，不是簡單地使用行加鎖的機制，而是選用一種叫做 多版本併發控制 mvcc，mutiversion concurrency control 的技術，和行加鎖機制關聯使用，以應對更多的併發處理問題。mvcc不是mysql獨有的技...