事物隔離級別就是通過mvcc做的，readCommitted：讀最新版本號的；repeadable read:讀同一個版本號的；
在併發讀寫數據庫時，讀操作可能會不一致的數據（髒讀）。爲了避免這種情況，需要實現數據庫的併發訪問控制，最簡單的方式就是加鎖訪問。由於，加鎖會將讀寫操作串行化，所以不會出現不一致的狀態。但是，讀操作會被寫操作阻塞，大幅降低讀性能。在java concurrent包中，有copyonwrite系列的類，專門用於優化讀遠大於寫的情況。而其優化的手段就是，在進行寫操作時，將數據copy一份，不會影響原有數據，然後進行修改，修改完成後原子替換掉舊的數據，而讀操作只會讀取原有數據。通過這種方式實現寫操作不會阻塞讀操作，從而優化讀效率。而寫操作之間是要互斥的，並且每次寫操作都會有一次copy，所以只適合讀大於寫的情況。
MVCC的原理與copyonwrite類似，全稱是Multi-Version Concurrent Control，即多版本併發控制。在MVCC協議下，每個讀操作會看到一個一致性的snapshot，並且可以實現非阻塞的讀。MVCC允許數據具有多個版本，這個版本可以是時間戳或者是全局遞增的事務ID，在同一個時間點，不同的事務看到的數據是不同的。
實現原理：
------------------------------------------------------------------------------------------> 時間軸
|-------R(T1)-----|
|-----------U(T2)-----------|
如上圖，假設有兩個併發操作R(T1)和U(T2)，T1和T2是事務ID，T1小於T2，系統中包含數據a = 1(T1)，R和W的操作如下：
R：read a (T1)
U：a = 2 (T2)
R（讀操作）的版本T1表示要讀取數據的版本，而之後寫操作纔會更新版本，讀操作不會。在時間軸上，R晚於U，而由於U在R開始之後提交，所以對於R是不可見的。所以，R只會讀取T1版本的數據，即a = 1。
由於在update操作提交之前，不能影響已有數據的一致性，所以不會改變舊的數據，update操作會被拆分成insert + delete。需要標記刪除舊的數據，insert新的數據。只有update提交之後，纔會影響後續的讀操作。而對於讀操作而且，只能讀到在其之前的所有的寫操作，正在執行中的寫操作對其是不可見的。
上面說了一堆的虛的理論，下面來點幹活，看一下mysql的innodb引擎是如何實現MVCC的。innodb會爲每一行添加兩個字段，分別表示該行創建的版本和刪除的版本，填入的是事務的版本號，這個版本號隨着事務的創建不斷遞增。在repeated read的隔離級別（事務的隔離級別請看這篇文章）下，具體各種數據庫操作的實現：
select：滿足以下兩個條件innodb會返回該行數據：（1）該行的創建版本號小於等於當前版本號，用於保證在select操作之前所有的操作已經執行落地。（2）該行的刪除版本號大於當前版本或者爲空。刪除版本號大於當前版本意味着有一個併發事務將該行刪除了。
insert：將新插入的行的創建版本號設置爲當前系統的版本號。
delete：將要刪除的行的刪除版本號設置爲當前系統的版本號。
update：不執行原地update，而是轉換成insert + delete。將舊行的刪除版本號設置爲當前版本號，並將新行insert同時設置創建版本號爲當前版本號。
其中，寫操作（insert、delete和update）執行時，需要將系統版本號遞增。
由於舊數據並不真正的刪除，所以必須對這些數據進行清理，innodb會開啓一個後臺線程執行清理工作，具體的規則是將刪除版本號小於當前系統版本的行刪除，這個過程叫做purge。
通過MVCC很好的實現了事務的隔離性，可以達到repeated read級別，要實現serializable還必須加鎖。