PostgreSQL MVCC 原始碼實現

      MVCC對每一個DBA來講，都不陌生，即多版本控制（Multi-Version-Control）。正因為資料有了多個版本，才實現了讀和寫在一定程度上的分離，提高資料庫每秒處理查詢的能力（QPS）。

使用者發起的普通查詢請求（不包含select … for update語句），並不堵塞DML事務。在Read Commit事務隔離級別時，查詢請求只讀取查詢請求之前已經提交的事務的資料更改，對當前版本的資料並不影響；

而DML語句，會操作當前版本。因此做到了讀寫分離的目的，提高資料庫併發能力。

      不同的資料庫，實現MVCC的方法不同。Oracle和MySQL Innodb 儲存引擎類似的使用undo來實現。

      對於PostgreSQL資料庫來講，他沒有undo，那麼，PG又是怎麼來實現他自己的MVCC呢？又有那些優缺點呢？

 

     PG用copy tuple和tuple的xmin,xmax,cmin,cmax等標記來實現多版本。

     xmin：在建立記錄(tuple)時，記錄此時，後面每次update也會更新。

     xmax: 在刪除tuple或者lock時，記錄此時；如果記錄沒有被刪除，那麼此時為0。

     cmin和cmax：主要為標識在同一個事務中多個語句命令的序列值。用於同一個事務中實現版本可見性判斷。

 

1.下面我們先來看一下xmin和xmax的變化：

從上圖可以看出，4條記錄的xmin是一樣的，都是“390689”，這說明是在同一個事務中建立的。另外xmax都為“0”，說明都沒有被刪除。cmin和cmax都是1，說明是同一個命令建立的。

接下來，我們update一下id為1的記錄，看發生什麼情況：

update之後，並沒有提交，重新開起另外一個視窗，查詢：

我們看到，ID為1的記錄，只有xmin沒有變化，其它三個值都發生了變化，其中xmax變成了”390691”。

然後我把事務提交掉，再在新視窗中查詢：

我們看到，提交後，ID 為1的記錄，xmin變為“390691”，xmin增加了1；而xmax變成了0。

 

從上面的案例中，我們從表面上可以看出,xmin增加了。但是事實上，PostgreSQL在底層所做的事情，遠比這個要多。底層已經生成了一個新版本的tuple，新版本tuple的xmin等於老版本的xmax。

詳細的internal，我後面再展開講。

 

2.我們再來看一下cmin和cmax的變化：

我起一個事務，包含兩條update，一條update ID值為2的記錄，一條insert ID值為3的記錄：

事務“390694”中，cmin和cmax的值，依次遞增。從目前來看cmin和cmax實際上是同一個field。

原始碼定義如下，用union實現了CommandId，是一個combo command id。

 

因此，從上面的例子來看，PostgreSQL的mvcc實現是比較簡單的。只需要透過對比tuple header中xmin,xmax,cmin,cmax與當前的xid，就可以得到在scan tuple時，此tuple對於當前查詢的可視性。

可見性判斷邏輯：

 

但是也帶來了另外一個問題：就是在沒有undo的情況下，會導致空間的增長。因此PostgreSQL引入了vacumm後臺程式，來定期清理這些 DEAD tuple。

關於vacumm的原理，我後面開寫一篇文章。