innodb有四種事務隔離機制，read uncommitted、read committed、repeatted read、 serializable，隔離界別依次提高，而且基本靠鎖實現這些隔離級別，但眾所周知，鎖的消耗是很大的。當然，我們也都知道，mysql實現了一種樂觀鎖的機制，在select 時候加上 for update就可以了，而且我們知道樂觀鎖其實是不用鎖的，是靠資料的版本控制實現的，那麼到底是咋回事呢。

   mvcc，多版本併發控制，就是innodb為了減少對鎖的依賴而實現的一種併發環境下、非鎖依賴的可以正常訪問資料的機制，mvcc就是通過版本控制實現的，而樂觀鎖就是基於mvcc實現的。

  首先，innodb會在每行資料中隱藏兩列，表示資料的建立時間和刪除時間，但實際存放的不是時間，是修改的版本號，版本號來源於每一個事務id。

  例如，剛插入第一條資料的時候，我們預設事務id為1，實際是這樣儲存的

  可以看到，我們在content列插入了kobe這條資料，在create_version這列儲存了1，1是這次插入操作的事務id。

  然後我們將kobe修改為kobebryant，實際儲存是這樣的

   可以看到，update的時候，會先將之前的資料delete_version標記為當前新的事務id，也就是2，然後將新資料寫入，將新資料的create_version標記為新的事務id

   當我們刪除資料的時候，實際儲存是這樣的

   可以看到，當前資料行的delete_version列被置為了3，也就是當前事務id。

   由此當我們查詢一條記錄的時候，只有滿足以下兩個條件的記錄才會被顯示出來：

   1.當前事務id要大於或者等於當前行的create_version值，這表示在事務開始前這行資料已經存在了。

   2.當前事務id要小於delete_version值，這表示在事務開始之後這行記錄才被刪除。

   以上兩條規則，要是有一條不滿足，這說明在事務執行過程中有其他的事務對資料進行了操作，則不滿足條件的資料就不會被查詢出來。慶幸的是，innodb預設隔離機制為repeatted read，是可以用到mvcc的，所以我們不必為此過多擔憂!