MySQL InnoDB儲存引擎，實現的是基於多版本的併發控制協議——MVCC (Multi-Version Concurrency Control) (注：與MVCC相對的，是基於鎖的併發控制，Lock-Based Concurrency Control)。MVCC最大的好處，相信也是耳熟能詳：讀不加鎖，讀寫不衝突。在讀多寫少的OLTP應用中，讀寫不衝突是非常重要的，極大的增加了系統的併發效能，這也是為什麼現階段，幾乎所有的RDBMS，都支援了MVCC。

　　對於delete操作，innodb是通過先將要刪除的那一行標記為刪除，而不是馬上清除這一行，因為innodb實現了MVCC，這些undo段用來實現MVCC多版本機制。鎖不阻塞讀，讀也不阻塞寫，這樣大大提高了併發性。那麼在一致性讀的時候，怎麼才能找到和事務開始的那個版本呢？

	主鍵索引，每個行都有一個事務ID和一個undo ID，這個undo ID指向了這行的先前版本的位置。
	非主鍵索引(輔助索引secondary index），通過先找主鍵索引再找到undo段。而對於update操作，則是先標記刪除，然後insert一個新的行，接下來如果有一致性讀，那麼查詢old version的行的原理和delete操作是一樣的

　　innoDB的行記錄格式中有6位元組事務ID的和7位元組的回滾指標，通過為每一行記錄新增這兩個額外的隱藏值來實現MVCC，這兩個值一個記錄這行資料何時被建立，另外一個記錄這行資料何時過期（或者被刪除）。但是InnoDB並不儲存這些事件發生時的實際時間，相反它只儲存這些事件發生時的系統版本號。這是一個隨著事務的建立而不斷增長的數字。每個事務在事務開始時會記錄它自己的系統版本號。每個查詢必須去檢查每行資料的版本號與事務的版本號是否相同。讓我們來看看當隔離級別是REPEATABLE READ時這種策略是如何應用到特定的操作的。

 * SELECT：
當隔離級別是REPEATABLE READ時select操作，InnoDB必須每行資料來保證它符合兩個條件：
1、InnoDB必須找到一個行的版本，它至少要和事務的版本一樣老(也即它的版本號不大於事務的版本號)。這保證了不管是事務開始之前，或者事務建立時，或者修改了這行資料的時候，這行資料是存在的。
2、這行資料的刪除版本必須是未定義的或者比事務版本要大。這可以保證在事務開始之前這行資料沒有被刪除。
符合這兩個條件的行可能會被當作查詢結果而返回。
* INSERT：
InnoDB為這個新行記錄當前的系統版本號。
* DELETE：
InnoDB將當前的系統版本號設定為這一行的刪除ID。
* UPDATE：
InnoDB會寫一個這行資料的新拷貝，這個拷貝的版本為當前的系統版本號。它同時也會將這個版本號寫到舊行的刪除版本里。
這種額外的記錄所帶來的結果就是對於大多數查詢來說根本就不需要獲得一個鎖。他們只是簡單地以最快的速度來讀取資料，確保只選擇符合條件的行。這個方案的缺點在於儲存引擎必須為每一行儲存更多的資料，
做更多的檢查工作，處理更多的善後操作。
MVCC只工作在REPEATABLE READ和READ COMMITED隔離級別下。READ UNCOMMITED不是MVCC相容的，因為查詢不能找到適合他們事務版本的行版本；它們每次都只能讀到最新的版本。
SERIABLABLE也不與MVCC相容，因為讀操作會鎖定他們返回的每一行資料。

併發控制技術：

LBCC：Lock-Based Concurrency Control，基於鎖的併發控制。
MVCC：Multi-Version Concurrency Control，基於多版本的併發控制協議。純粹基於鎖的併發機制併發量低，MVCC是在基於鎖的併發控制上的改進，主要是在讀操作上提高了併發量。
在MVCC併發控制中，讀操作可以分成兩類：
1）快照讀 (snapshot read)：讀取的是記錄的可見版本 (有可能是歷史版本)，不用加鎖（共享讀鎖s鎖也不加，所以不會阻塞其他事務的寫）。
2）當前讀 (current read)：讀取的是記錄的最新版本，並且，當前讀返回的記錄，都會加上鎖，保證其他事務不會再併發修改這條記錄。