MySQL中的多版本併發控制

基於提高併發效能的考慮，mysql中大多數事務型儲存引擎實現的都不是簡單的行級鎖，一般都同時實現了多版本併發控制（mvcc）

可以將多版本併發控制視為行級鎖的乙個變種，但是在很多情況下，它都能避免了加鎖操作，因此開銷更低。雖然實現機制有所不同，但是大都實現了非阻塞式的讀操作，寫操作也只鎖定了必要的行。

mvcc的實現，是通過儲存資料在某個時間點的快照來實現的。

因此不管需要執行多長時間，每個事務看到的資料都是一致的。根據事務開始的時間不同，每個事務對同一張表，同一時刻看到的資料可能是不一樣的。

下面通過innodb的簡化版來說明mvcc是如何工作的。

innodb的mvcc是通過在每行記錄後儲存兩個隱藏的列來實現的。這兩個列，乙個儲存了行的建立時間，乙個儲存行的過期時間（或者是刪除時間）。當然儲存的不是實際的時間值，而是系統版本號。

每當開始乙個新的事務，系統版本號都會自動遞增，事務開始時刻的系統版本號作為事務的版本號，用來和查詢到的每行記錄的版本號進行比較。

下面就select、insert、delete和update進行說明。

select

innodb會根據下面兩個條件檢查每行記錄：

1.innodb之查詢版本號小於等於當前事務版本的資料行，這樣可以確保事務讀取的行要麼是在事務開始前已經存在的，要麼就是事務自身插入或者修改過的。

2.行的刪除版本要麼未定義，要麼大於當前事務版本號。這樣可以確保事務讀取到的行，在事務開始前未被刪除。

只有符合上述兩個條件的記錄，才能作為查詢結果被返回。

insert

innodb為新插入的每一行儲存當前系統版本號作為行版本號。

delete

innodb為刪除的每一行儲存當前系統版本號作為行刪除標識。

update

innodb會插入一條新記錄，儲存當前系統版本號為行版本號，同時儲存當前系統版本號到原來的行作為行刪除標識。

儲存這兩個額外的系統版本號，使大多數的讀操作都不用加鎖，這樣的設計使得讀資料操作很簡單，效能很好，並且只會讀取到符合標準的行。不足之處是每行記錄都需要額外的儲存空間，需要做更多額外的檢查工作和維護工作。

需要注意的是，mvcc只在repeatable read和read committed兩個隔離級別下工作，其他兩個級別都和mvcc「不相容」。因為read uncommitted總是讀取最新的資料行，而serializable則會對所有讀取的行都加鎖。

更多技術乾貨點這裡就對了