多版本併發控制 MVCC
MySQL的大多數事務型儲存引擎實現的都不是簡單的行級鎖。基於提升併發效能的考慮，它們一般都同時實現了多版本併發控制（MVCC）。不僅是MySQL，包括Oracle、PostgreSQL等其他資料庫系統也都實現了MVCC，但各自的實現機制不盡相同，因為MVCC沒有一個統一的實現標準。
可以認為MVCC是行級鎖的一個變種，但是它在很多情況下避免了加鎖操作，因此開銷更低。雖然實現機制有所不同，但大都實現了非阻塞的讀操作，寫操作也只鎖定必要的行。
MVCC的實現，是透過儲存資料在某個時間點的快照來實現的。也就是說，不管需要執行多長時間，每個事務看到的資料都是一致的。根據事務開始的時間不同，每個事務對同一張表，同一時刻看到的資料可能是不一樣的。如果之前沒有這方面的概念，這句話聽起來就有點迷惑。熟悉了以後會發現，這句話其實還是很容易理解的。
前面說到不同儲存引擎的MVCC實現是不同的，典型的有樂觀（optimistic）併發控制和悲觀（pessimistic）併發控制。下面我們透過InnoDB的簡化版行為來說明MVCC是如何工作的。
InnoDB的MVCC，是透過在每行記錄後面儲存兩個隱藏的列來實現的。這兩個列，一個儲存了行的建立時間，一個儲存行的過期時間（或刪除時間）。當然儲存的並不是實際的時間值，而是系統版本號（system version number）。每開始一個新的事務，系統版本號都會自動遞增。事務開始時刻的系統版本號會作為事務的版本號，用來和查詢到的每行記錄的版本號進行比較。下面看一下在REPEATABLE READ 隔離級別下，MVCC具體是如何操作的。
SELECT
InnoDB會根據以下兩個條件檢查每行記錄：
-
a. InnoDB只查詢版本早於當前事務版本的資料行（也就是，行的``系統版本號小於或等於事務的系統版本號`），這樣可以確保事務讀取的行，要麼是在事務開始前已經存在的，要麼是事務自身插入或者修改過的。
-
b. 行的
刪除版本要麼未定義，要麼大於當前事務版本號。這可以確保事務讀取到的行，在事務開始之前未被刪除。
只有符合上述兩個條件的記錄，才能返回作為查詢結果。
INSERT
InnoDB為新插入的每一行儲存當前系統版本號作為行版本號。
DELETE
InnoDB為刪除的每一行儲存當前系統版本號作為行刪除標識。
UPDATE
InnoDB為插入一行新記錄，儲存當前系統版本號作為行版本號，同時儲存當前系統版本號到原來的行作為行刪除標識。
儲存這兩個額外系統版本號，使大多數讀操作都可以不用加鎖。這樣設計使得讀資料操作很簡單，效能很好，並且也能保證只會讀取到符合標準的行。不足之處是每行記錄都需要額外的儲存空間，需要做更多的行檢查工作，以及一些額外的維護工作。
MVCC只在REPEATABLE READ 和READ COMMITTED 兩個隔離級別下工作。其他兩個隔離級別都和MVCC不相容 (4) ，因為READ UNCOMMITTED總是讀取最新的資料行，而不是符合當前事務版本的資料行。而SERIALIZABLE則會對所有讀取的行都加鎖。