MVCC全稱是： Multiversion concurrency control，多版本併發控制，提供併發訪問資料庫時，對事務內讀取的到的記憶體做處理，用來避免寫操作堵塞讀操作的併發問題。
舉個例子，程式設計師A正在讀資料庫中某些內容，而程式設計師B正在給這些內容做修改（假設是在一個事務內修改，大概持續10s左右），A在這10s內 則可能看到一個不一致的資料，在B沒有提交前，如何讓A能夠一直讀到的資料都是一致的呢？
有幾種處理方法，第一種： 基於鎖的併發控制，程式設計師B開始修改資料時，給這些資料加上鎖，程式設計師A這時再讀，就發現讀取不了，處於等待情況，只能等B操作完才能讀資料，這保證A不會讀到一個不一致的資料，但是這個會影響程式的執行效率。還有一種就是：MVCC，每個使用者連線資料庫時，看到的都是某一特定時刻的資料庫快照，在B的事務沒有提交之前，A始終讀到的是某一特定時刻的資料庫快照，不會讀到B事務中的資料修改情況，直到B事務提交，才會讀取B的修改內容。
一個支援MVCC的資料庫，在更新某些資料時，並非使用新資料覆蓋舊資料，而是標記舊資料是過時的，同時在其他地方新增一個數據版本。因此，同一份資料有多個版本儲存，但只有一個是最新的。
MVCC提供了 時間一致性的 處理思路，在MVCC下讀事務時，通常使用一個時間戳或者事務ID來確定訪問哪個狀態的資料庫及哪些版本的資料。讀事務跟寫事務彼此是隔離開來的，彼此之間不會影響。假設同一份資料，既有讀事務訪問，又有寫事務操作，實際上，寫事務會新建一個新的資料版本，而讀事務訪問的是舊的資料版本，直到寫事務提交，讀事務才會訪問到這個新的資料版本。
MVCC有兩種實現方式，第一種實現方式是將資料記錄的多個版本儲存在資料庫中，當這些不同版本資料不再需要時，垃圾收集器回收這些記錄。這個方式被PostgreSQL和Firebird/Interbase採用，SQL Server使用的類似機制，所不同的是舊版本資料不是儲存在資料庫中，而儲存在不同於主資料庫的另外一個數據庫tempdb中。第二種實現方式只在資料庫儲存最新版本的資料，但是會在使用undo時動態重構舊版本資料，這種方式被Oracle和MySQL/InnoDB使用。
MVCC全稱是： Multiversion concurrency control，多版本併發控制，提供併發訪問資料庫時，對事務內讀取的到的記憶體做處理，用來避免寫操作堵塞讀操作的併發問題。
舉個例子，程式設計師A正在讀資料庫中某些內容，而程式設計師B正在給這些內容做修改（假設是在一個事務內修改，大概持續10s左右），A在這10s內 則可能看到一個不一致的資料，在B沒有提交前，如何讓A能夠一直讀到的資料都是一致的呢？
有幾種處理方法，第一種： 基於鎖的併發控制，程式設計師B開始修改資料時，給這些資料加上鎖，程式設計師A這時再讀，就發現讀取不了，處於等待情況，只能等B操作完才能讀資料，這保證A不會讀到一個不一致的資料，但是這個會影響程式的執行效率。還有一種就是：MVCC，每個使用者連線資料庫時，看到的都是某一特定時刻的資料庫快照，在B的事務沒有提交之前，A始終讀到的是某一特定時刻的資料庫快照，不會讀到B事務中的資料修改情況，直到B事務提交，才會讀取B的修改內容。
一個支援MVCC的資料庫，在更新某些資料時，並非使用新資料覆蓋舊資料，而是標記舊資料是過時的，同時在其他地方新增一個數據版本。因此，同一份資料有多個版本儲存，但只有一個是最新的。
MVCC提供了 時間一致性的 處理思路，在MVCC下讀事務時，通常使用一個時間戳或者事務ID來確定訪問哪個狀態的資料庫及哪些版本的資料。讀事務跟寫事務彼此是隔離開來的，彼此之間不會影響。假設同一份資料，既有讀事務訪問，又有寫事務操作，實際上，寫事務會新建一個新的資料版本，而讀事務訪問的是舊的資料版本，直到寫事務提交，讀事務才會訪問到這個新的資料版本。
MVCC有兩種實現方式，第一種實現方式是將資料記錄的多個版本儲存在資料庫中，當這些不同版本資料不再需要時，垃圾收集器回收這些記錄。這個方式被PostgreSQL和Firebird/Interbase採用，SQL Server使用的類似機制，所不同的是舊版本資料不是儲存在資料庫中，而儲存在不同於主資料庫的另外一個數據庫tempdb中。第二種實現方式只在資料庫儲存最新版本的資料，但是會在使用undo時動態重構舊版本資料，這種方式被Oracle和MySQL/InnoDB使用。