幾個系統(tǒng)字段的介紹
在面試中讽膏，我們經(jīng)常會遇到這樣一個問題：
如果你的表中有十萬條數(shù)據(jù)，當你做了一次查詢后贤笆，開始依次讀取數(shù)據(jù)，當你讀取到第 1000 行時讨阻，這時候芥永，有人使用 UPDATE 語句修改了 1001 行數(shù)據(jù)，請問如果繼續(xù)讀到 1001 行數(shù)據(jù)時钝吮，你會讀取到最新的數(shù)據(jù)嗎埋涧？為什么？
這個問題粗看起來和我們之前提到的隔離級別有點關系奇瘦，仔細一想好像不是棘催，因為這次修改是發(fā)生在讀取中，這個場景在日常開發(fā)中很常見耳标，在 JDBC 中你遍歷 ResultSet 或者 ADO 與 ODBC 中你移動 cursor醇坝，總之，在你讀取數(shù)據(jù)的時候次坡，數(shù)據(jù)發(fā)生了改變呼猪，這在并發(fā)環(huán)境下是很常見的。當然了砸琅，大多數(shù)人的答案是不會讀取到的郑叠，但是這是 MVCC （Multiversion Concurrency Control，多版本并發(fā)控制）的策略與實現(xiàn)后所產生的結果明棍，簡單來說，每個事務讀到的數(shù)據(jù)項都是一個歷史快照（snapshot）寇僧，但是要解釋為什么摊腋，就需要繼續(xù)學習了（我們將討論控制在 PostgreSQL 中，其他 RDBMS 的行為在此就不分析與討論了）嘁傀。
在 PostgreSQL 中每個表都存在一些隱藏的系統(tǒng)字段兴蒸，因此你是不能使用這些隱藏字段的名字作為列名的，在 psql 中细办，我們使用 \d 命令也不會打印出這些字段橙凳，但是這并不表示他們不存在蕾殴，對于我們這些普通的數(shù)據(jù)庫使用者來說，我們只需要知道他們存在就足夠了岛啸，但是如果你想了解 PostgreSQL 更深一些钓觉，你還是需要稍微學習一下。這里坚踩，我們只介紹四個字段荡灾，這四個字段可以幫助我們理解 PostgreSQL 的 MVCC 是如何工作的，讓我們能夠更好的回答剛開始提到的那個問題：
- xmin: 插入此當前行版本（row version）的事務 Id瞬铸，注意批幌，row version 與 row 是不同的兩個東西，而且 UPDATE 會創(chuàng)建一個新行并帶著新的版本號嗓节，所以 xmin 實際上是 INSERT 和 UPDATE 此行的事務 Id荧缘。
- xmax: 刪除這行的事務 Id，對于沒有刪除的行版本（row version）這個值為 0拦宣，如果在事務中查詢到這個值不為 0 就表示刪除的事務還沒提交截粗，或者嘗試刪除的操作被回滾了。
- cmin: 事務內部插入恢着、更新操作的命令 ID凿掂。
- cmax: 事務中刪除操作的命令 ID，或者 0靶壮。
查看這四個字段也很簡單种蝶，直接查詢就可以了，可以看到創(chuàng)建這條記錄的事務 ID靡羡。
select xmin,xmax,cmin,cmax, name from users where id = 10;
xmin | xmax | cmin | cmax | name
------+------+------+------+------------
627 | 0 | 0 | 0 | d3d9446802
(1 row)
關于更多的系統(tǒng)字段系洛，可以參閱 DDL System Columns。
怎么用這四個字段略步？
在我們開始 MVCC 之前描扯，先學習一下這四個字段的用法，對于 PostgreSQL 來說存在一個行版本 （row version）的說法趟薄，這個行版本的叫法不準確绽诚，這個詞表示這樣的情況：對于一行記錄 row，存在多個版本 version杭煎，而這幾個字段自然是會隨著版本的不同而被改變的恩够，他們的改變規(guī)則如下：
- 當新增一條數(shù)據(jù)時，新的行中的 xmin 就是當前事務的 ID羡铲，xmax 是 0蜂桶。
- 當更新一條數(shù)據(jù)時，實際上是新增了一條新的記錄也切，舊行上 xmin 不變扑媚，但是 xmax 是當前事務 ID （因為標記被刪除了）腰湾，然后新的行中的 xmin 就是當前事務的 ID，xmax 是 0（這時候當前行就有兩個版本了）疆股。
- 刪除一行時费坊，被刪除的行 xmax 是當前事務 ID。
所以總結一下押桃，不論你是什么 SQL 命令引起的行變化葵萎，如果是創(chuàng)建了新行，xmin 是當前事務 ID唱凯，如果是刪除了舊行羡忘，xmax 就是刪除的事務的 ID，這里特別要注意的是磕昼，UPDATE 命令會更新數(shù)據(jù)卷雕，但是實際上是新增了數(shù)據(jù)。而行的版本票从，就有點像 git漫雕，你是可以看到舊的歷史記錄，但是一般來說我們關心最新的（只有舊的事務峰鄙，才關心舊的）浸间。
為了驗證之前我們提到的規(guī)則，我們還是開啟兩個 terminal吟榴，在 T1 中魁蒜，我們進行如下操作：
for_test=# BEGIN;
BEGIN
for_test=# select txid_current();
txid_current
--------------
640
(1 row)
for_test=# update users set name = 'updated' where id = 10;
UPDATE 1
for_test=# select xmin,xmax,cmin,cmax, name from users where id = 10;
xmin | xmax | cmin | cmax | name
------+------+------+------+---------
640 | 0 | 0 | 0 | updated
(1 row)
可以看到，T1 在沒有 commit 前吩翻，新列的 xmin 已經(jīng)是 T1 的 ID 640 了兜看，這時候，如果你在 T2 進行查詢狭瞎，你應該會看到:
for_test=# select xmin,xmax,cmin,cmax, name from users where id = 10;
xmin | xmax | cmin | cmax | name
------+------+------+------+---------
627 | 640 | 0 | 0 | d3d9446802
(1 row)
xmax 不為 0 時表示這一行已經(jīng)被刪除了细移，但是還沒有提交，這時候熊锭，如果 T1 進行 COMMIT弧轧，T2 再進行查詢，結果便是：
for_test=# select xmin,xmax,cmin,cmax, name from users where id = 10;
xmin | xmax | cmin | cmax | name
------+------+------+------+---------
640 | 0 | 0 | 0 | updated
可以看到 xmin 是 T1 的事務 ID 640碗殷，xmax 已經(jīng)是 0 了劣针。這里留一個思考，如果 T2 中執(zhí)行的這兩句命令在一個事務中亿扁，結果會是一樣的嗎？為什么鸟廓？
對于 cmin 和 cmax 是為了解決一個事務中命令的順序問題的从祝，作用沒有 xmax 與 xmin 大襟己。在一個事務中，命令的 ID 是會自增的牍陌，請允許我借用這個例子：
pgsql=# begin;
BEGIN
pgsql=# select * from tab01;
id | cd
----+----
(0 rows)
pgsql=# select xmin,xmax,cmin,cmax,* from tab01;
xmin | xmax | cmin | cmax | id | cd
------+------+------+------+----+----
(0 rows)
pgsql=# insert into tab01 values(1,'1'),(2,'2'),(3,'3');
INSERT 0 3
pgsql=# insert into tab01 values(4,'4'),(5,'5'),(6,'6');
INSERT 0 3
pgsql=# select xmin,xmax,cmin,cmax,* from tab01;
xmin | xmax | cmin | cmax | id | cd
------+------+------+------+----+----
1897 | 0 | 0 | 0 | 1 | 1
1897 | 0 | 0 | 0 | 2 | 2
1897 | 0 | 0 | 0 | 3 | 3
1897 | 0 | 1 | 1 | 4 | 4
1897 | 0 | 1 | 1 | 5 | 5
1897 | 0 | 1 | 1 | 6 | 6
(6 rows)
insert into tab01 values(1,'1'),(2,'2'),(3,'3'); 的 command ID 是 0擎浴，insert into tab01 values(4,'4'),(5,'5'),(6,'6'); 是 1，這時候毒涧，如果第一條 command 是一個 select 并且返回了一個 cursor贮预，然后我們又執(zhí)行了 command 2 加入了三條數(shù)據(jù)，這是在一個事務中的契讲，這時候仿吞，cursor 繼續(xù)讀取或者修改數(shù)據(jù)，但是后面三條數(shù)據(jù)的 cmin 是 1 比自己的 0 大捡偏，所以這三條數(shù)據(jù)是不可見的唤冈，也就是不能讀到的，這就是 cmin 和 cmax 的意義银伟。但是 cmax 實際上和 cmin 是一個值你虹，請參考 cmin 與 cmax 的社區(qū)討論。
MVCC & VACUUM
了解了上面的四個系統(tǒng)字段彤避，我們就可以簡略的說一下 PostgreSQL 的 MVCC 是怎么實現(xiàn)的了傅物。之前我們的問題中提到，不論是讀的時候發(fā)生了寫琉预，還是寫的時候我正在讀取董饰，都會產生數(shù)據(jù)不一致的問題，實際上我們希望的是在讀取的瞬間模孩，數(shù)據(jù)是不變的尖阔，這樣的好處是大于一半新數(shù)據(jù)，一半老數(shù)據(jù)的情況的榨咐，那最簡單的辦法就是加鎖介却，不論是讀還是寫都給表上加鎖，就像是 synchronized 關鍵字一樣块茁，但是任何環(huán)境齿坷、編程語言下都會降低性能，所以有人提出了快照的概念数焊，實際上在讀取的時候永淌，依舊讀取的是舊數(shù)據(jù)，而寫數(shù)據(jù)時并不刪除佩耳，這就解決了這個問題遂蛀。
對于 PostgreSQL，實現(xiàn)的方式就是我們剛才講到的 row version干厚，寫入或更新新數(shù)據(jù)時并不修改原數(shù)據(jù)李滴，只創(chuàng)建新行就行螃宙。這種方式實現(xiàn)起來相對比較簡單，因為不需要移動與刪除舊數(shù)據(jù)所坯，所以我們需要有 xmin xmax cmin cmax 的標記來幫助事務判斷版本谆扎，顯而易見的缺點是當數(shù)據(jù)被刪除后，也是存留在磁盤中芹助，我們的空間依舊是被占用的堂湖。
還有一點值得注意的是，對于事務所產生的修改數(shù)據(jù)状土，會有 xmin 與 xmax 的標記无蜂，但是如果事務回滾，PostgreSQL 也不會刪除這些創(chuàng)建的數(shù)據(jù)声诸，這也是為了性能而采取的措施酱讶，當我們需要去回收存儲空間時，就可以通過 xmin 與 xmax 去找事務是否成功來進行回收了彼乌，而事務的成功與否存在于 commit log 中泻肯。
下來，就需要非常重要的 VACUUM 命令了慰照，VACUUM 命令是一個垃圾回收器灶挟，會清除我們之前提到的無效的、廢棄的數(shù)據(jù)毒租，所以周期性的使用 vacuum 進行回收是非常重要的稚铣。直接使用 VACUUM 會處理當前數(shù)據(jù)庫中的每一張表，你當然也可以指定某一張表墅垮。對于 VACUUM 的參數(shù)惕医，有兩個參數(shù)值得我們注意：
- FULL: 有點類似于 stop the world 的 full GC，F(xiàn)ULL 參數(shù)會給我們騰出更多的空間算色，但是會鎖表抬伺，也需要很多的空間，因為實際上 VACUUM FULL 是把當前表進行了一次拷貝灾梦！所以峡钓，使用 VACUUM FULL 需要非常留心，除非你必須要騰出很多空間若河，或者能接受停機能岩，否則盡量別用它。
- ANALYZE: 更新查詢分析器的統(tǒng)計數(shù)據(jù)萧福，幫助我們的查詢計劃能夠更精確拉鹃，很多人在業(yè)務不繁忙時手動進行 VACUUM 的情況下會加入 ANALYZE 參數(shù)，這樣能顯著的提高查詢性能。
當然 VACUUM 是 PostgreSQL 獨有的命令膏燕，并不是 SQL 標準炭庙。而且默認下 PostgreSQL 的 autovacuum 是打開的，PostgreSQL 很智能的在更新達到一定情況下會使用 VACUUM煌寇，這就是為什么很多使用 PostgreSQL 的同學沒有用過 VACUUM 的原因之一了。這里查看 autovacuum 文檔介紹逾雄。
所以阀溶，PostgreSQL 的 MVCC 使我們考慮事務就比較簡單了，筆者曾經(jīng)在一個事務中進行了百萬次的插入鸦泳，并不需要特別擔心什么银锻，即使出錯 ROLLBACK 也是一瞬間的事情，因為并不做物理刪除做鹰，所以在插入击纬、修改的時候，性能還是比較穩(wěn)定的钾麸，但是我們不得不消耗系統(tǒng)資源去進行垃圾回收更振，這就如同 Java GC 一樣，VACUUM 進程的回收也是要消耗資源的饭尝。
