任何一個數據庫最主要功能之一是可擴展。如果不刪除彼此，則儘可能較少鎖競爭從而達到這個目的。由於read、write、update、delete是數據庫中最主要且頻繁進行的操作，所以併發執行這些操作時不被阻塞則顯得非常重要。爲了達到這種目的，大部分數據庫使用多版本併發控制（Multi-Version Concurrency Control）這種併發模型。這種模型能夠將競爭減少到最低限度。
MVCC是什麼
Multi Version Concurrency Control ( MVCC)是這樣的一種算法：通過對同一個對象維護多個版本，提供一種很好的併發控制技術，這種技術能夠使READ和WRITE操作不發生衝突。這裏的WRITE指的是UPDATE和DELETE，不包含Insert是因爲新插入的記錄可以通過各自的隔離級別進行保護。每個WRITE操作使對象產生一個新版本，每個併發讀操作依賴於隔離級別讀取對象不同的版本。由於READ和WRITE操作同一個對象的不同版本，所以這些操作不需要將對象完全鎖住，因此這些操作能夠併發執行。當然當兩個併發事務WRITE同一個記錄時，這些鎖競爭還是會存在的。
當前大部分數據庫系統都支持MVCC。這個算法的核心是對相同對象維護不同版本，因此不同數據庫創建並維護多版本的方式不同，其實現方式也不同。相應地，數據庫操作和數據存儲也發生變化。
實現MVCC最常見的方法：PostgreSQL使用的方法、InnoDB和Oracle的使用方法。下面我們會詳細討論PG和InnoDB的實現方式。
PostgreSQL中的MVCC
爲了支持多版本，PG對每個對象（PG術語：Tuple）增加了額外的字段：
1、xmin：進行插入或更新操作事務的事務ID。UPDATE中，對tuple的新版本分配該事務ID。
2、xmax：進行刪除或更新操作事務的事務ID。UPDATE中，對當前存在的tuple分配該事務ID。新創建的tuple，該字段默認爲null。
PostgreSQL將所有數據存儲在HEAP中（每頁默認8KB）。新記錄的xmin爲創建該記錄的事務的事務ID；老版本（進行update或delete）其xmax爲進行操作的事務的ID。會有一個鏈表將老版本和新版本連接起來。在回滾的過程中，老版本記錄可以被重用；依賴於隔離級別，READ語句讀取一個老版本記錄進行返回。
例如下面兩條記錄：T1（值爲1）、T2（值爲2），通過下面3步對記錄的創建進行演示：
從圖中可以看出，數據庫中初始時存在兩個記錄：1和2。
第二步，將2更新爲3。此時創建一個新值，並存放到同一個存儲區域的下一個位置。老版本2爲其xmax分配該事務的ID，並且指向最新的版本記錄。
同理，第三步，當T1被刪除時，對記錄進行虛擬刪除（爲其xmax分配當前事務ID），該操作不存在創建新記錄版本。
下面，通過實例講解每個操作如何創建多版本，不用加鎖如何實現事務的隔離級別。下面例子中使用默認隔離級別“READ COMMITTED”。
INSERT
每次insert一個記錄，都會新創建一個tuple並將其存儲到表文件的頁中。
可以看到：
1、Session-A開啓一個事務，其事務ID爲495
2、Session-B開啓一個事務，其事務ID爲496
3、Session-A插入一個tuple，存儲到HEAP
4、新tuple的xmin爲495，而xmax爲null
5、由於Session-A的事務沒有提交，session-B看不到第3步插入的值
6、Session-A提交
7、都可以看到新插入的tuple
UPDATE
PostgreSQL的UPDATE不是“IN-PLACE”更新，不會將現有對象更新替換爲新值，而是新創建一個新對象。因此UPDATE涉及以下幾步：
1、將當前對象標記爲deleted
2、插入對象的一個新版本
3、將對象的老版本指向新版本
因此，即使許多記錄保持不變，HEAP也會佔用空間，就像新插入另一個記錄一樣。
如上所示：
1、Session-A開啓一個事務，其事務ID爲497
2、Session-B開啓一個事務，其事務ID爲498
3、Session-A更新一個現有記錄
4、Session-A可以看到tuple的最新版本而Session-B看到另一個老版本。Session-A看到新記錄的xmin爲497,xmax爲null；Session-B看到老版本xmin是495，xmax爲497即Session-A的事務ID。這兩個tuple版本都存在HEAP中，如果空間允許甚至存在同一頁中。
5、Session-A提交事務，老版本消失
6、現在所有會話都可以看到記錄的同一個版本。
DELETE
DELETE操作和UPDATE類似，只是不會添加一個新版本。如UPDATE，只是將當前對象標記爲已刪除。
1、Session-A開啓一個事務，事務ID爲499
2、Session-B開啓一個事務，事務ID爲500
3、Session-A刪除現有記錄
4、Session-A看不到當前事務已刪除的記錄；Session-B看到老版本，其xmax爲499，499的事務刪除的該記錄
5、Session-A提交事務，老版本記錄消失
6、所有會話都看不到之前的老版本
可以看到，這些操作都不會直接刪除現有記錄，如果需要會添加一個附加版本。
我們來看看SELECT在多版本中怎麼執行：依賴於隔離級別，SELECT需要讀取tuple的所有版本直到找到合適的tuple。假設有一個tuple T1，被更新爲新版本T1’，然後再被更新爲T1’’：
1、SELECT操作進入這個表的heap中，首先檢查T1，如果T1的xmax事務已提交，查找該tuple的下一個版本
2、T1’也被提交，查找下一個版本
3、]最後找到T1’’看到xmax未提交或者爲null，然後T1’’的xmin可見，最後讀取T1’’這個tuple。
可以看到需要遍歷該tuple的3個版本才能找到合適的可見版本，直到VACUUM進程回收了打上delete標籤的記錄。
InnoDB中的MVCC
爲了支持多版本，InnoDB對行記錄又額外維護了幾個字段：
1、DB_TRX_ID：插入或更新航記錄的事務的事務ID
2、DB_ROLL_PTR：即回滾指針，指向回滾段中的undo log record
與PostgreSQL相比，InnoDB也會創建行記錄的多版本，但是存儲老版本的方式不同。
InnoDB將行記錄的老版本存放到獨立的表空間/存儲空間（回滾段）。和PostgreSQL不同，InnoDB僅將行記錄最新版本存儲到表的表空間中，而將老版本存放到回滾段。回滾段中的undo log作用：用來進行回滾操作；依賴於隔離級別，進行多版本讀，讀取老版本。
例如，兩行記錄：T1（值爲1），T2（值爲2），可以通過下面3步說明新記錄的創建過程：
從上圖可以看到，初始時，表中有兩條記錄1和2。
第二階段，行記錄T2值2被更新爲3。此時記錄創建一個新版本並替代老版本。老版本存儲到回滾段（注意，回滾段中的數據僅包含更改值，即delta value），同時新版本行記錄中的回滾指針指向回滾段中的老版本。和PostgreSQL不同，InnoDB更新是“IN-PLACE”。
同理，第三步，刪除T1然後將其標記爲虛擬刪除（僅在行記錄指定的一個bit位上打上delete標籤）並在回滾段中插入一個對應的新版本。同樣回滾指針指向回滾段中undo log。
從表面上看，所有操作表象與PostgreSQL相同，只是多版本在內部存儲方式不同。
MVCC：PostgreSQL vs InnoDB
下面分析PostgreSQL和InnoDB的MVCC主要不同在哪幾方面：
1、老版本的大小
PostgreSQL僅更新tuple老版本的xmax，因此老版本的大小和相應插入的記錄大小相同。這意味着，如果一個older tuple有3個版本，那麼他們大小都相同（如果更新的值大小不同，每次更新時實際大小就不同）。
InnoDB的老版本存儲到回滾段，且比對應的插入記錄小，因爲InnoDB僅將變化的值寫到undo log。
2、INSERT操作
INSERT時，InnoDB會向回滾段寫入額外的記錄，而PostgreSQL僅在UPDATE中創建新版本。
3、回滾時恢復老版本
回滾時，PostgreSQL不用任何特定內容，需注意老版本的xmax等於update該記錄的事務ID。因此在併發快照中該記錄認爲是alive的直到該事務ID的事務提交。
而InnoDB，一旦回滾，需要重新構造對象的老版本。
4、]回收老版本佔用的空間
PG中，老版本佔用的空間僅在沒有併發快照使用時纔可以被回收，此時被認爲dead。然後VACCUM可以回收空間。VACCUM可以手動觸發也可以依賴於配置在後臺任務中觸發。
InnoDB的undo log分爲INSERT UNDO和UPDATE UNDO。事務提交後，就會立即釋放INSERT UNDO。當沒有其他併發快照使用時，纔可以釋放UPDATE UNDO。InnoDB沒有顯示VACUUM操作但是有類似的PURGE回收undo log。
5、延遲vacuum的影響
如前所示，PostgreSQL延遲vacuum存在很大影響。即使頻繁執行delete，它將會引起表膨脹造成佔用的存儲空間暴增。這還會造成到達一個點後，需要執行一個高額代價的操作VACUUM FULL。
6、表膨脹時的順序掃描
即使所有記錄都是dead狀態，PostgreSQL的順序掃描也會掃描對象所有的老版本，直到執行vacuum將dead的記錄刪除。這是PG中常見且經常討論的問題。主要PG將一個tuple的所有老版本都存儲到同一個存儲區域。
而InnoDB，除非需要，否則不需要讀取undo log。如果所有undo記錄都已失效，那麼只需要讀取所有對象的最新版本既可。
7、索引
PostgreSQL獨立存儲索引，並將索引連接到HEAP中的真實數據。因此即使沒有更改索引，有時也需要更新索引。隨後這個問題被HOT（Heap Only Tuple）解決，但是仍有限制，如果相同頁空間不足，則退回到正常UPDATE操作。
InnoDB由於使用聚集索引，不會有這樣的問題。
結論
PostgreSQL的MVCC有一些缺點，尤其是具有頻繁UPDATE/DELETE負載時，會引起表膨脹。因此決定選擇PG時，需要慎重配置VACUUM。
PG社區已經意識到這個問題，已經開始涉及基於undo的MVCC（暫命名爲ZHEAP），我們在未來版本可以看到這個特性。
原文
https://severalnines.com/blog/comparing-data-stores-postgresql-mvcc-vs-innodb