PostgreSQL事务篇—— 事务与多版本并发控制MVCC

?、 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()函数获取

三个特殊的txid

0：InvalidTransactionId，表??效的事务ID

1：BootstrapTransactionId，表?系统表初始化时的事务ID，?任何普通的事务ID都旧。

2：FrozenTransactionId，冻结的事务ID，?任何普通的事务ID都旧。

?于2的事务ID都是普通的事务ID。

事务间的可?性

txid间可以相互?较??，任何事务只可?txid＜其??txid的事务修改结果。但txid并不是?限的，当42亿数据?尽之后?应该如何判断可?性？

2. 元组结构

pg中元组由三部分组成——元组头结点、空值位图、?户数据。

其中与MVCC相关的重要信息为：

t_xmin：保存插?该元组的事务txid（该元组由哪个事务插?）

t_xmax：保存更新或删除该元组的事务txid。若该元组尚未被删除或更新，则

t_xmax=0，即invalid

t_cid：保存命令标识（command id,cid），指在该事务中，执?当前命令之前还执?过?条sql命令（从0开始计算）

t_ctid：?个指针，保存指向??或新元组的元组的标识符（tid）。

当更新该元组时，t_ctid会指向新版本元组。若元组被更新多次，则该元组会存在多个版本，各版本通过t_cid串联，形成?个版本链。通过这个版本链，可以找到最新的版本。

t_ctid是?个?元组（?号,?内偏移量），其中?号从0开始，?内偏移量从1开始。

三、 元组的增、删、改

1. 插?

插?操作最简单，直接将新元组插??标表中??即可

插?操作的过程和结果分析：

• t_xmin 被设置为99，表?插?该元组的txid
• t_xmax 被设置为0，因为该元组还未被更新或删除过
• t_cid 被设置为0，因为这是该事务的第?条命令
• t_ctid 指向??，被设置为（0,1），表?该元组位于0号page的第1个位置上

2. 删除

pg的删除只是将?标元组在逻辑上标为删除（将t_xmax设为执?delete命令的事务txid），实际该元组依然存在于数据库的存储??，直?该元组被清理进程清理掉。

删除操作的过程和结果分析：

• t_xmin 不变，表?插?该元组的txid
• t_xmax 被设置为111，即删除该元组的txid
• t_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 不变，表?插?该元组的txid
• t_xmax 被设置为100，即删除该元组的txid
• t_cid 被设置为0，因为这是该事务的第?条命令
• t_ctid 指向新版本元组，被设置为（0,2），表?新元组位于0号page的第2个位置上

Tuple_2

• t_xmin 被设置为100，表?插?该元组的txid
• t_xmax 被设置为0，因为该元组还未被更新或删除过
• t_cid 被设置为0，因为这是该事务的第?条命令（虽然?删?增，实际都是?条update操作的）
• t_ctid 指向??，被设置为（0,2），表?该元组位于0号page的第2个位置上

再看第?条update：

Tuple_2

• t_xmin 不变，表?插?该元组的txid
• t_xmax 被设置为100，即删除该元组的txid
• t_cid 被设置为1，因为这是该事务的第?条命令
• t_ctid 指向新版本元组，被设置为（0,3），表?新元组位于0号page的第3个位置上

Tuple_3

• t_xmin 被设置为100，表?插?该元组的txid
• t_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状态?于?事务，此处不讨论。

四种事务状态仅需两个bit即可记录。以?个块8KB为例，可以存储8KB*8/2 = 32K个事务的状态。内存中缓存CLOG的buffer ??为Min(128,Max(4,NBuffers/512))。

2. ?作原理

CLOG在逻辑上是?个数组，由共享内存中?系列8K??组成。数组下标对应事务txid，数组内容则为事务状态：

• T1时刻：txid=200事务提交，对应状态从IN_PROGRESS改为COMMITED
• T2时刻：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??和?件。