一、 MVCC常用实现方法
一般MVCC有2种实现方法：
写新数据时，把旧数据快照存入其他位置（如oracle的回滚段、sqlserver的tempdb）。当读数据时，读的是快照的旧数据。写新数据时，旧数据不删除，直接插入新数据。PostgreSQL就是使用的这种实现方法。
1. PostgreSQL的MVCC实现方式优缺点
优点
无论事务进行了多少操作，事务回滚可以立即完成数据可以进行很多更新，不必像Oracle和MySQL的Innodb引擎需要保证回滚段不会被用完，也不会经常遇到“ORA-1555”错误的困扰
缺点
旧版本的数据需要清理。当然，PostgreSQL 9.x版本中已经增加了自动清理的辅助进程来定期清理旧版本的数据可能会导致查询需要扫描的数据块增多，从而导致查询变慢
2. PostgreSQL中MVCC的实现思路
为了实现MVCC机制，必须要：
定义多版本的数据——使用元组头部信息的字段来标示元组的版本号定义数据的有效性、可见性、可更新性——通过当前的事务快照和对应元组的版本号判断实现不同的数据库隔离级别——通过在不同时机获取快照实现
下面我们分别来看，首先了解一些基本概念。
二、 基本概念
1. 事务标识
当事务开始（执行begin第一条命令时），事务管理器会为该事务分配一个txid（transaction id）作为唯一标识符。txid是一个32位无符号整数，取值空间大小约42亿（2^32-1）。
txid可通过txid_current()函数获取
testdb=# BEGIN;BEGINtestdb=# SELECT txid_current();txid_current --------------100(1 row)
三个特殊的txid
0：InvalidTransactionId，表示无效的事务ID1：BootstrapTransactionId，表示系统表初始化时的事务ID，比任何普通的事务ID都旧。2：FrozenTransactionId，冻结的事务ID，比任何普通的事务ID都旧。大于2的事务ID都是普通的事务ID。
事务间的可见性
txid间可以相互比较大小，任何事务只可见txid＜其自身txid的事务修改结果。但txid并不是无限的，当42亿数据用尽之后又应该如何判断可见性？这个问题我们下篇再讨论。
2. 元组结构
pg中元组由三部分组成——元组头结点、空值位图、用户数据。
官方文档中解释如下PostgreSQL: Documentation: 9.6: Database Page Layout
其中与MVCC相关的重要信息为：
t_xmin：保存插入该元组的事务txid（该元组由哪个事务插入）t_xmax：保存更新或删除该元组的事务txid。若该元组尚未被删除或更新，则t_xmax=0，即invalidt_cid：保存命令标识（command id,cid），指在该事务中，执行当前命令之前还执行过几条sql命令（从0开始计算）t_ctid：一个指针，保存指向自身或新元组的元组的标识符（tid）。
当更新该元组时，t_ctid会指向新版本元组。若元组被更新多次，则该元组会存在多个版本，各版本通过t_cid串联，形成一个版本链。通过这个版本链，可以找到最新的版本。t_ctid是一个二元组（页号,页内偏移量），其中页号从0开始，页内偏移量从1开始。
pg提供了pageinspect插件，可查看指定表对应的page header内容
testdb=# CREATE EXTENSION pageinspect;CREATE EXTENSIONtestdb=# CREATE TABLE tbl (data text);CREATE TABLEtestdb=# INSERT INTO tbl VALUES('A');INSERT 0 1testdb=# SELECT lp as tuple, t_xmin, t_xmax, t_field3 as t_cid, t_ctid FROM heap_page_items(get_raw_page('tbl', 0));tuple | t_xmin | t_xmax | t_cid | t_ctid -------+--------+--------+-------+--------1 |99 |0 |0 | (0,1)(1 row)
三、 元组的增、删、改
1. 插入
插入操作最简单，直接将新元组插入目标表中页面即可
插入操作的过程和结果分析：
t_xmin 被设置为99，表示插入该元组的txidt_xmax 被设置为0，因为该元组还未被更新或删除过t_cid 被设置为0，因为这是该事务的第一条命令t_ctid 指向自身，被设置为（0,1），表示该元组位于0号page的第1个位置上
2. 删除
pg的删除只是将目标元组在逻辑上标为删除（将t_xmax设为执行delete命令的事务txid），实际该元组依然存在于数据库的存储页面，直至该元组被清理进程清理掉。
删除操作的过程和结果分析：
t_xmin 不变，表示插入该元组的txidt_xmax 被设置为111，即删除该元组的txidt_cid 被设置为0，因为这是该事务的第一条命令t_ctid 指向自身，被设置为（0,1），表示该元组位于0号page的第1个位置上
当txid=111的事务提交时，tuple_1就不再需要了，称为dead tuple。但是这个tuple依然残留在页面上， 随着数据库的运行，这种死元组越来越多，它们会在VACUUM时最终被清理掉。
3. 更新
pg不会直接修改数据，而是将目标元组标记为删除，并插入一条新元组，同时修改t_ctid执行新版本元组。
更新操作的过程和结果分析
首先看第一条update：
Tuple_1
t_xmin 不变，表示插入该元组的txidt_xmax 被设置为100，即删除该元组的txidt_cid 被设置为0，因为这是该事务的第一条命令t_ctid 指向新版本元组，被设置为（0,2），表示新元组位于0号page的第2个位置上
Tuple_2
t_xmin 被设置为100，表示插入该元组的txidt_xmax 被设置为0，因为该元组还未被更新或删除过t_cid 被设置为0，因为这是该事务的第一条命令（虽然又删又增，实际都是一条update操作的）t_ctid 指向自身，被设置为（0,2），表示该元组位于0号page的第2个位置上
再看第二条update：
Tuple_2
t_xmin 不变，表示插入该元组的txidt_xmax 被设置为100，即删除该元组的txidt_cid 被设置为1，因为这是该事务的第二条命令t_ctid 指向新版本元组，被设置为（0,3），表示新元组位于0号page的第3个位置上
Tuple_3
t_xmin 被设置为100，表示插入该元组的txidt_xmax 被设置为0，因为该元组还未被更新或删除过t_cid 被设置为1，因为这是该事务的第二条命令t_ctid 指向自身，被设置为（0,3），表示该元组位于0号page的第3个位置上
四、 提交日志
pg在提交日志（commit log,CLOG）中保存事务的状态。
1. 事务状态
pg定义了四种事务状态——IN_PROGRESS, COMMITTED, ABORTED和SUB_COMMITTED，其中SUB_COMMITTED状态用于子事务，此处不讨论。
#define TRANSACTION_STATUS_IN_PROGRESS0x00#define TRANSACTION_STATUS_COMMITTED0x01#define TRANSACTION_STATUS_ABORTED0x02#define TRANSACTION_STATUS_SUB_COMMITTED0x03
四种事务状态仅需两个bit即可记录。以一个块8KB为例，可以存储8KB*8/2 = 32K个事务的状态。内存中缓存CLOG的buffer 大小为Min(128,Max(4,NBuffers/512))。
2. 工作原理
CLOG在逻辑上是一个数组，由共享内存中一系列8K页面组成。数组下标对应事务txid，数组内容则为事务状态：
T1时刻：txid=200事务提交，对应状态从IN_PROGRESS改为COMMITEDT2时刻：txid=201事务回滚，对应状态从IN_PROGRESS改为ABORTED
当需要获取事务状态时，pg调用内部函数读取CLOG返回所请求事务状态，详情参考下篇——提示位。
3. CLOG的维护
当shutdown pg或Checkpoint运行时，CLOG数据会由内存写入pg_clog（pg 10后叫pg_xact）目录中的文件。这些文件被命名为0000,0001，最大256KB。当pg启动时，会加载这些文件用于初始化CLOG。
CLOG数据会不断增长，但并非所有数据都是必要的，清理过程也会定期清理掉不再需要的CLOG页面和文件。
参考
《postgresql实战》
The Internals of PostgreSQL : Chapter 5 Concurrency Control
PgSQL· 引擎特性 · 多版本并发控制介绍及实例分析
PgSQL · 特性分析 · MVCC机制浅析
PgSQL · 引擎特性 · PostgreSQL Hint Bits 简介
PostgreSQL: Documentation: 10: 67.6.Database Page Layout
如果觉得《pg事务篇（一）—— 事务与多版本并发控制MVCC》对你有帮助，请点赞、收藏，并留下你的观点哦！
