PostgreSQL MVCC 源码实现

MVCC对每一个DBA来讲，都不陌生，即多版本控制（Multi-Version-Control）。正因为数据有了多个版本，才实现了读和写在一定程度上

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 的下载地址：请点这里

本文永久更新链接地址：