openGauss源码解析（37）

openGauss源码解析：存储引擎源码解析（5）

3. astore元组多版本机制

openGauss行存储表支持多版本元组机制，即为同一条记录保留多个历史版本的物理元组以解决对同一条记录的读、写并发冲突（读事务和写事务工作在不同版本的物理元组上）。

astore存储格式为追加写优化设计，其多版本元组产生和存储方式如图4-5所示。当一个更新操作将v0版本元组更新为v1版本元组之后，如果v0版本元组所在页面仍然有空闲空间，则直接在该页面内插入更新后的v1版本元组，并将v0版本的元组指针指向v1版本的元组指针。在这个过程中，新版本元组以追加写的方式和被更新的老版本元组混合存放，这样可以减少更新操作的I/O开销。然而，需要指出的是，由于新、老版本元组是混合存放的，因此在清理老版本元组时需要的清理开销会比较大。因此，astore存储格式比较适合频繁插入、少量更新的业务场景。

图4-5 astore多版本元组产生和存储方式示意图

下面结合图4-6，介绍openGauss中行存储格式多版本元组的运行机制：

图4-6 行存储格式多版本元组运行机制示意图

（1） 首先事务号为10的事务插入一条值为value1的新记录。对应的页面修改为：在0号物理页面的第一个元组指针指向位置，插入一条“xmin”字段为10、“xmax”字段为0、“ctid”字段为（0，1）、“data”字段为value1的物理元组。该事务提交，将CSN从3推进到4，并且在CSN日志中对应事务号10的槽位处记下该CSN的值。

（2） 然后事务号为12的事务将上面这条记录的值从value1修改为value2。对应的页面修改为：在0号物理页面的第二个元组指针指向位置，插入另一条“xmin”字段为12、“xmax”字段为0、“ctid”字段为（0，2）、“data”为value2的物理元组。同时保留上面第一条插入的物理元组，但是将其“xmax”字段从0修改为12，将其“ctid”字段修改为（0，2），即新版本元组的物理位置。该事务提交，将CSN从7推进到8，并且在CSN日志中对应事务号12的槽位处记下该CSN的值。

（3） 最后事务号为15的事务将上面这条记录的值从value2又修改为value3，对应的页面修改为：（假设0号页面已满）在1号物理页面的第一个元组指针指向位置，插入一条“xmin”字段为15、“xmax”字段为0、“ctid”字段为（1，1）、“data”字段为value3的物理元组；同时，保留上面第1、第2条插入的物理元组，但是将第2条物理元组的“xmax”字段从0修改为15，将其“ctid”字段修改为（1，1），即最新版本元组的物理位置。该事务提交，将CSN从9推进到10，并且在CSN日志中对应事务号15的槽位处记下该CSN的值。

（4） 对于并发的读事务，其在查询执行开始时，会获取当前的全局CSN值作为查询的快照CSN。对于上面同一条记录的3个版本的物理元组来说，该读查询操作只能看到同时满足如下两个条件的这个物理元组版本。

➀ 元组“xmin”字段对应的CSN值小于等于读查询的快照CSN。

➁ 元组“xmax”字段为0，或者元组“xmax”字段对应的CSN值大于读查询的快照CSN。

比如，若并发读查询的快照CSN为8，那么这条查询将看到value2这条物理元组；若并发读查询的快照CSN为11，那么这条查询将看到value3这条物理元组。

对于不同的行存储子格式，上述多版本元组的格式和存储方式可能有所不同，但是可见性判断和并发控制方式都是如图4-6中所示的。通过上面介绍的元组可见性判断流程，可以发现：并发的读事务会根据自己的查询快照在同一个记录的多个历史版本元组中选择合适的那个来返回。并且即使是在可重复读的事务隔离级别下，只要使用相同的快照总可以筛选出相同的那个历史版本元组。在整个过程中读事务不阻塞任何对该记录的并发写操作（更新和删除）。

更详细的元组可见性判断流程将在第5章中详细介绍。

最后，对于astore行存储格式，更新一条记录的详细执行流程如图4-7所示，该图可以帮助读者更形象地理解多版本元组的产生流程，以及写、写并发下的处理逻辑。

图4-7 更新astore记录的执行流程示意图