1.4. 多版本併發控制
大多數的mysql事務型儲存引擎，如innodb，falcon以及pbxt都不使用一種簡單的行鎖機制。事實上，他們都和和另外一種用來增加併發性的被稱為「多版本併發控制（mvcc）」的機制來一直使用。mvcc不只使用在mysql中，oracle，postgresql以及其他一些資料為系統也同樣使用它。
你可將將mvcc看成行級別鎖的一種妥協，它在許多情況下避免了使用鎖，同時可以提供更小的開銷。根據實現的不同，它可以允許非阻塞式讀，在寫操作進行時只鎖定必要的記錄。
mvcc會儲存某個時間點上的資料快照。這意味闃事務可以看到乙個一致的資料檢視，不管他們需要跑多久。這同時也意味著不同的事務在同乙個時間點看到的同乙個表的資料可能是不同的。如果你從來沒有過種體驗的話，可能理解起來比較抽象，但是隨著慢慢地熟悉這種理解將會很容易。
各個儲存引擎對於mvcc的實現各不相同。這些不同中的一些包括樂觀和悲觀併發控制。我們將通過乙個簡化的innodb版本的行為來展示mvcc工作的乙個側面。
innodb：通過為每一行記錄新增兩個額外的隱藏的值來實現mvcc，這兩個值乙個記錄這行資料何時被建立，另外乙個記錄這行資料何時過期（或者被刪除）。但是innodb並不儲存這些事件發生時的實際時間，相反它只儲存這些事件發生時的系統版本號。這是乙個隨著事務的建立而不斷增長的數字。每個事務在事務開始時會記錄它自己的系統版本號。每個查詢必須去檢查每行資料的版本號與事務的版本號是否相同。讓我們來看看當隔離級別是repeatable read時這種策略是如何應用到特定的操作的：
select innodb必須每行資料來保證它符合兩個條件：
1、innodb必須找到乙個行的版本，它至少要和事務的版本一樣老(也即它的版本號不大於事務的版本號)。這保證了不管是事務開始之前，或者事務建立時，或者修改了這行資料的時候，這行資料是存在的。
2、這行資料的刪除版本必須是未定義的或者比事務版本要大。這可以保證在事務開始之前這行資料沒有被刪除。
符合這兩個條件的行可能會被當作查詢結果而返回。
insert：innodb為這個新行記錄當前的系統版本號。
delete：innodb將當前的系統版本號設定為這一行的刪除id。
update：innodb會寫乙個這行資料的新拷貝，這個拷貝的版本為當前的系統版本號。它同時也會將這個版本號寫到舊行的刪除版本裡。
這種額外的記錄所帶來的結果就是對於大多數查詢來說根本就不需要獲得乙個鎖。他們只是簡單地以最快的速度來讀取資料，確保只選擇符合條件的行。這個方案的缺點在於儲存引擎必須為每一行儲存更多的資料，做更多的檢查工作，處理更多的善後操作。
mvcc只工作在repeatable read和read commited隔離級別下。read uncommited不是mvcc相容的，因為查詢不能找到適合他們事務版本的行版本；它們每次都只能讀到最新的版本。seriablable也不與mvcc相容，因為讀操作會鎖定他們返回的每一行資料。
表1-2總結了mysql中不同的鎖模型以及併發級別。
圖表 1‑2 mysql中使用預設隔離級別下的鎖模型以及併發級別
多版本併發控制
多版本併發控制，討論的不是指的乙個軟體同時發行多個版本怎麼進行管理的問題，而是mysql中的mvcc。mvcc，multiple version concurrent control，多版本併發控制。可以認為mvcc是行級鎖的乙個變種，但它在很多情況下避免了加鎖操作，因此開銷更低。雖然實現機制有所不...
多版本併發控制（MVCC）
mysql的大多數事務性儲存引擎 如innodb 實現的都不是簡單的行級鎖。基於提公升併發效能的考慮，它們一般都同時實現了多版本併發控制 mvcc 可以認為mvcc是行級鎖的乙個變種，但是它在很多情況下避免了加鎖操作，因此開銷更低。雖然實現機制有所不同，但大都實現了非阻塞的讀操作，寫操作也只鎖定必要...
多版本併發控制MVCC
大多數mysql的事務性儲存引擎，例如innodb.falcon 和pbxt，不是簡單地使用行加鎖的機制，而是選用一種叫做 多版本併發控制 mvcc，mutiversion concurrency control 的技術，和行加鎖機制關聯使用，以應對更多的併發處理問題。mvcc不是mysql獨有的技...