MVCC原理

多版本并发控制（Multi-Version Concurrency Control， MVCC） ， 是数据库中并发访问数据时保证数据一致性的一种方法。

在并发操作中， 当正在写时， 如果有用户在读， 这时写可能只写了一半， 如一行的前半部分刚写入， 后半部分还没有写入， 这时可能读的用户读取到的数据行的前半部分数据是新的， 后半部分数据是原来的， 这就导致了数据一致性问题。

解决这个问题的最简单的方法是使用读写锁， 写的时候不允许读， 正在读的时候也不允许写， 但这种方法会导致读和写的操作不能并发执行。
于是， 有人想到了一种能够让读写并发执行的方法， 这种方法就是MVCC。
MVCC方法是写数据时， 原数据并不删除， 并发的读还能读到原数据， 这样就不会有数据一致性问题了。

实现MVCC的方法有以下两种：

• 第一种： 写新数据时， 把原数据移到一个单独的位置， 如回滚段中， 其他用户读数据时， 从回滚段中把原数据读出来。
• 第二种： 写新数据时， 原数据不删除， 而是把新数据插入进来。

PostgreSQL数据库使用的是第二种方法， 而Oracle数据库和MySQL数据库中的InnoDB引擎使用的是第一种方法。

PostgreSQL中的多版本并发控制

PostgreSQL中的多版本实现是通过把原数据留在数据文件中， 新插入一条数据来实现多版本的功能的。
每张表上都有4个系统字段“xmin”“xmax”“cmin”“cmax”， 这4个字段就是为多版本的功能而添加的。

xmin、 xmax、 cmin、 cmax这4个字段在多版本实现中用于控制数据行是否对用户可见。
PostgreSQL将修改前后的数据存储在相同的结构中， 分为以下几种情况：

• 新插入一行时， 将新插入行的xmin填写为当前的事务ID， xmax填“0”。

• 修改这一行时， 实际上新插入一行， 原数据行上的xmin不变， xmax改为当前的事务ID， 新数据行上的xmin填为当前的事务ID， xmax填“0”。

如下图所示，lp=2 和 lp=3 的 t_ctid 都是 (0,3)。这说明 UPDATE 操作产生的新旧版本共享同一个 ctid 槽位引用（新版本指向自身，旧版本的 t_ctid 在 UPDATE 时未被修改），但它们是两个独立的物理元组，通过 xmin/xmax 形成版本链。

通过 pageinspect 插件直接读取页面原始内容查看旧行数据

SELECT lp, -- 行指针编号 (Line Pointer) t_ctid, -- 元组的 ctid t_xmin, -- 插入事务ID t_xmax, -- 删除/更新事务ID t_infomask2, -- 属性标志位（含 cmin/cmax） t_hoff, -- 头部长度 t_data -- 原始用户数据（bytea 十六进制） FROM heap_page_items(get_raw_page('t1', 0));

• 删除一行时， 把被删除行上的xmax填写当前的事务ID，xmax不等于0不一定是死元组

从上面的叙述中就可以知道， xmin就是标记插入数据行的事务ID， 而xmax就是标记删除数据行的事务ID。没有修改数据行的操作， 因为修改数据行， 实际上就是把原数据行上的xmax标记上自己的事务ID（相当于打上删除标记） ， 然后再新插入一条记录。所以最新版本的数据即xmax为0的一条。

当两个事务同时访问记录时， 通过参考xmin和xmax的标记判断记录的版本， 根据版本号与自己当前的事务标识进行比较， 确定自己的数据权限。
当删除数据时， 记录并没有从数据块中被删除， 空间也没有立即释放。

PostgreSQL的多版本实现中首先要解决的是原数据的空间释放问题。
PostgreSQL通过运行Vaccum进程来回收之前的存储空间， 默认PostgreSQL数据库中的AutoVacuum是打开
的， 也就是说， 当一个表的更新量达到一定值时（死元组数>50+(0.2×活行数）， AutoVacuum自动回收空间。
当然也可以关闭AutoVacuum进程， 然后在业务低峰期手动运行VACUUM命令来回收空间。

在PostgreSQL中， 若一个事务执行失败， 在数据文件中该事务产生的数据并不会在事务回滚时被清理掉。 为什么要这样做呢？ 为什么不在事务提交时把这些数据标记成有效，而在事务回滚时把这些数据标记成无效呢？
这是出于效率的考虑。
若事务提交或回滚时再次标记数据， 那这些数据就有可能会被刷新到磁盘中， 再次标记会导致另一次I/O， 从而降低性能。

那么如何知道这些数据是有效还是无效呢？
PostgreSQL通过记录事务的状态来实现。
数据行上记录了xmin和xmax， 只需了解xmin和xmax对应的事务是成功提交还是回滚了， 就可以知道这些数据行是否有效。

PostgreSQL把事务状态记录在pg_xact（旧版本中被称为pg_clog），在数据目录的pg_xact子目录下，

但是pg_xact是一个二进制文件目录不能直接查询，可以通过内置函数 txid_status()确定事务是提交还是回滚

committed: 事务已成功提交 aborted: 事务已回滚（中止） in progress: 事务仍在运行中 null: 事务 ID 太老，状态信息已被清理（见下文“事务 ID 回卷”）

PostgreSQL多版本的优劣分析

Oracle数据库和MySQL数据库的InnoDB引擎也都实现了多版本的功能， 但它们与PostgreSQL的实现方式是不一样的， 在这两个数据库中， 旧版本的数据并不记录在原先的数据块中， 而是被记录在回滚段中， 如果要读取旧版本的数据， 需要根据回滚段的数据重构旧版本数据。

PostgreSQL的多版本机制与Java虚拟机的垃圾回收机制比较相像。
事务提交前， 只需要访问原来的数据即可； 提交后， 系统更新元组的存储标识， 直到Vaccum进程收回为止。

相对于InnoDB和Oracle， PostgreSQL的多版本的优势在于以下几点：

• 事务回滚可以立即完成， 无论事务进行了多少操作。
• 数据可以进行很多更新， 不必像Oracle和InnoDB那样需要经常保证回滚段不会被用完， 也不会像Oracle数据库那样， 经常遇到“ORA-1555”错误的困扰。

相对于InnoDB和Oracle， PostgreSQL的多版本的劣势在于以下几点：

• 旧版本数据需要清理。 PostgreSQL清理旧版本称为VACUUM， 并提供了VACUUM命令进行清理。
• 旧版本的数据会导致查询更慢一些， 因为旧版本的数据存储于数据文件中， 查询时需要扫描更多的数据块。