本文主要向您展示“PostgreSQL MVCC源代码示例分析”，简单易懂，条理清晰，希望能帮您解惑。让边肖带领你学习和研究文章《PostgreSQL MVCC源代码示例分析》。
MVCC对每个数据库管理员来说都不陌生，那就是多版本控制。只是因为数据有多个版本，在一定程度上实现了读写分离，提高了数据库每秒的查询处理能力(QPS)。
用户发起的普通查询请求(不包括更新语句的select …请求)不会阻塞DML事务。在读取提交事务隔离级别，查询请求只读取在查询请求之前提交的事务的数据更改，对数据的当前版本没有影响。
DML语句将在当前版本上运行。从而达到读写分离的目的，提高数据库的并发性。
不同的数据库有不同的MVCC实现方式。类似于Oracle MySQL Innodb存储引擎，是通过撤销实现的。
对于PostgreSQL数据库，他没有撤销，那么PG如何实现自己的MVCC呢？有哪些优点和缺点？
使用PG copytuple和tuple的xmin、xmax、cmin、cmax等标签实现多版本。
Xmin:创建记录(元组)时，记录将在此时以及每次后续更新时更新。
Xmax:在删除元组或锁时记录此时间；如果记录尚未删除，则此时为0。
Cmin和cmax:主要用于标识同一事务中多个语句命令的序列值。用于实现同一事务中的版本可见性判断。
1.下面我们先来看一下xmin和xmax的变化：
从上图可以看出，这四条记录的xmin是相同的，都是“390689”，这意味着它们是在同一个事务中创建的。此外，xmax都是“0”，这意味着它们都没有被删除。Cmin和cmax都是1，这意味着它们是由同一个命令创建的。
接下来，让我们更新id为1的记录，看看会发生什么：
更新后未提交，再次打开另一窗口查询：
我们可以看到，对于ID为1的记录，只有xmin没有变化，其他三个值都发生了变化，其中xmax变成了“390691”。
然后我提交事务，并在新窗口中进行查询：
我们看到提交后，ID为1，xmin的记录变为“390691”，xmin增加1；xmax变成0。
从上面的例子中，我们可以从表面上看到xmin增加了。但事实上，PostgreSQL在底层做的远不止这些。新版本的tuple已经在底部生成，新版本tuple的xmin等于旧版本的xmax。
详细内部，我以后再说。
2.我们再来看一下cmin和cmax的变化：
我启动一个事务，它包含两个更新，一个更新标识值为2的记录和一个插入标识值为3的记录：
在交易“390694”中，cmin和cmax的值依次增加。目前cmin和cmax其实是同一个领域。
源代码定义如下。CommandId由union实现，它是一个组合命令Id。
因此，从上面的例子来看，在PostgreSQL中实现mvcc是比较简单的。只有通过将xmin、xmax、cmin、cmax扫描元组头与当前xid进行比较，我们才能在扫描元组时得到这个元组对于当前查询的可见性。
可见性判断逻辑：
但也带来了另一个问题：没有撤销，会导致空间的增长。因此，PostgreSQL引入了vacumm后台进程来定期清理这些DEAD元组。
以上是文章《PostgreSQL MVCC源代码示例分析》的全部内容。感谢您的阅读！相信大家都有一定的了解，希望分享的内容对大家有所帮助。想了解更多知识，请关注行业资讯频道！
内容来源网络，如有侵权，联系删除，本文地址：https://www.230890.com/zhan/118544.html