引言
MySQL的大多數事務型存儲引擎實現的都不是簡單的行級鎖。基於提升併發性能的考慮，它們一般都同時實現了多版本併發控制——MVCC。包括其他數據庫如Oracle等，由於MVCC並沒有一個統一的實現標準，因此它們的實現原理都不盡相同。
MVCC簡介
可以認爲MVCC是行級鎖的一個變種。但是它在很多情況下避免了加鎖操作，因此開銷很低。一般都實現了非阻塞的讀操作，同時寫操作也只是鎖定必要的行。
MVCC的實現，是通過保存數據在某個時間點的快照來實現的。也就是說，不管需要執行多長時間，每個事務看到的數據都是一致的。根據事務開始的時間不同，每個事務對同一張表，同一時刻看到的數據可能是不一樣的。
MVCC的不同實現，大致可分爲樂觀派併發控制，和悲觀派併發控制。
InnoDB的MVCC，是通過在每行記錄後面保存兩個隱藏的列來實現的。這兩個列，一個保存了行的創建時間，一個保存行的過期時間（或刪除時間）。但存儲的並不是實際的時間值，而是系統版本號。每開始一個新的事務，系統版本號都會自動遞增。事務開始時刻的系統版本號會作爲事務的版本號，用來和查詢到的每行記錄的版本號進行比較。
這裏可以簡單瞭解一下在REPEATABLE READ 隔離級別下，MVCC具體是如何查詢的。
InnoDB會根據一下兩個條件檢查每行記錄：
1、InnoDB只查找版本早於當前事務版本的數據行，即行的版本號小於或等於事務的系統版本號。這樣可以確保事務讀取的行，要麼是在事務開始前已經存在的，要麼是事務自身插入或修改過的。
2、行的刪除版本號要麼未定義，要麼大於當前事務版本號。這可以確保事務讀取到的行，在事務開始之前未被刪除。
只有符合上述兩個條件的記錄，才能返回作爲查詢結果。
保存這兩個額外的系統版本號，使大多數讀操作都可以不用加鎖。這樣設計使得讀數據操作很簡單，性能很好，並且也能保證只會讀取到符合標準的行。
MVCC只在REPEATABLE READ 和 READ COMMITTED兩個隔離級別下工作。其他兩個隔離級別和MVCC不兼容。因爲READ UNCOMMITTED總是讀取最新的數據行，而不是符合當前事務版本的數據行；而SERIALIZABLE則會對所有讀取的行都加鎖。