PostgreSQL MVCC 源碼實現

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的原理，我後面開寫一篇文章。

------------------------------------華麗麗的分割線------------------------------------

CentOS 6.3環境下yum安裝PostgreSQL 9.3

PostgreSQL緩衝詳述

Windows平台編譯 PostgreSQL

Ubuntu下LAPP（Linux+Apache+PostgreSQL+PHP)環境的配置與安裝

Ubuntu上的phppgAdmin安裝及配置

CentOS平台下安裝PostgreSQL9.3

PostgreSQL配置Streaming Replication叢集

如何在CentOS 7/6.5/6.4 下安裝PostgreSQL 9.3 與 phpPgAdmin 

------------------------------------華麗麗的分割線------------------------------------

PostgreSQL 的詳細介紹：請點這裡
PostgreSQL 的：請點這裡

本文永久更新連結地址：