《PostgreSQL技术内幕——原理探索》第七章 堆内元组与仅索引扫描

本章中介绍两个和索引扫描有关的特性—— 堆内元组（heap only tuple, HOT）和仅索引扫描（index-only scan） 。

7.1 堆内元组（HOT）

在8.3版本中实现的HOT特性，使得更新行的时候，可以将新行放置在老行所处的同一个数据页中，从而高效地利用索引与表的数据页；HOT特性减少了不必要的清理过程。

在源码的README.HOT中有关于HOT的详细介绍，本章只是简短的介绍HOT。首先，7.1.1节描述了在没有HOT特性的时候，更新一行是怎样一个过程，以阐明要解决的问题。接下来，在7.1.2中将介绍HOT做了什么。

7.1.1 没有HOT时的行更新

假设表tbl有两个列：id和data；id是tbl的主键。

表tbl有1000条元组；最后一个元组的id是1000，存储在第五个数据页中。最后一条元组被相应的索引元组所引用，索引元组的key是1000，且tid是(5,1)，如图7.1(a)所示。

图 7.1 没有HOT的行更新

我们考虑一下，没有HOT特性时，最后一个元组是如何更新的。

在该场景中，PostgreSQL不仅要插入一条新的表元组，还需要在索引页中插入新的索引元组，如图7.1(b)所示。索引元组的插入消耗了索引页的空间，而且索引元组的插入和清理都是开销很大的操作。HOT的目的，就是降低这种影响。

7.1.2 HOT如何工作

当使用HOT特性更新行时，如果被更新的元组存储在老元组所在的页面中，PostgreSQL就不会再插入相应的索引元组，而是分别设置新元组的HEAP_ONLY_TUPLE标记位与老元组的HEAP_HOT_UPDATED标记位，两个标记位都保存在元组的t_informask2字段中。如图7.2和7.3所示；

图7.2 HOT的行更新

比如在这个例子中，Tuple_1和Tuple_2分别被设置成HEAP_HOT_UPDATED和HEAP_ONLY_TUPLE。

另外，在修剪（pruning）和碎片整理（defragmentation）处理过程中，都会使用下面介绍的HEAP_HOT_UPDATED和HEAP_ONLY_TUPLE标记位。

接下来会介绍，当基于HOT更新一个元组后，PostgreSQL是如何在索引扫描中访问这些被HOT更新的元组的，如图7.4(a)所示。

图7.4 行指针修剪

1. 找到指向目标数据元组的索引元组
2. 按所获索引元组指向的位置访问行指针数组，找到行指针1
3. 读取Tuple_1
4. 经由Tuple_1的t_ctid字段，读取Tuple_2。

在这种情况下，PostgreSQL会读取两条元组，Tuple_1和Tuple_2，并通过第5章所述的并发控制机制来判断哪条元组是可见的；但如果数据页中的死元组（dead tuple）已经被清理了，那就有问题了。比如在图7.4(a)中，如果Tuple_1由于是死元组而被清理了，就无法通过索引访问Tuple_2了。

为了解决这个问题，PostgreSQL会在合适的时候进行行指针重定向：将指向老元组的行指针重新指向新元组的行指针。在PostgreSQL中，这个过程称为修剪（pruning）。图7.4(b)说明了PostgreSQL在修剪之后如何访问更新的元组。

1. 找到索引元组
2. 通过索引元组，找到行指针[1]
3. 通过重定向的行指针[1]，找到行指针[2]；
4. 通过行指针[2]，读取Tuple_2

可能的话，剪枝任何时候都有可能会发生，比如 SELECT ，UPDATE， INSERT ，DELETE这类SQL命令执行的时候，确切的执行时机不会在本章中描述，因为它太复杂了。细节可以在README.HOT文件中找到。

在PostgreSQL执行剪枝时，如果可能，会挑选合适的时机来清理死元组。在PostgreSQL中这种操作称为碎片整理（defragmentation），图7.5中描述了HOT中的碎片整理过程。

图 7.5 死元组的碎片整理

后续精彩内容已被小麦苗无情隐藏，请输入验证码解锁本站所有文章

验证码：

请关注本站微信公众号，回复“小麦苗博客”，获取验证码。在微信里搜索“DB宝”或者“www_xmmup_com”或者微信扫描右侧二维码都可以关注本站微信公众号。