1、HOT概述

PostgreSQL中，由于其多版本的特性，當我們進行數據更新時，實際上并不是直接修改元數據，而是通過新插入一行數據來進行間接的更新。而當表上存在索引時，由于新插入了數據，那么索引必然也需要同步進行更新，這在索引較多的情況下，對于更新的性能影響必然很大。

為了解決這一問題，pg從8.3版本開始就引入了HOT（Heap Only Tuple）機制。其原理大致為，當更新的不是索引字段時，我們通過將舊元組指向新元組，而原先的索引不變，仍然指向舊元組，但是我們可以通過舊元組作為間接去訪問到新的元組，這樣就不用再去更新索引了。

2、HOT實現技術細節

要使用HOT進行更新，需要滿足兩個前提：

• 新的元組和舊元組必須在同一個page中；
• 索引字段不能進行更新。

當我們進行HOT更新時，首先是分別設置舊元組的t_informask2標志位為HEAP_HOT_UPDATED和新元組為HEAP_ONLY_TUPLE。

更新如下圖所示：

我們更新tuple1為tuple2，分別設置這兩行元組的t_informask2標志位，然后tuple1的ctid指向tuple2，而tuple2指向自己。

但是這樣存在一個明顯的問題，我們都知道pg會定期進行vacuum清理那些死元組，那么我們這里如果通過tuple1去訪問tuple2的話，tuple1這個死元組被清理了又該怎么辦呢？

所以pg會在合適的時機進行行指針的重定向，將舊元組的行指針指向新元組的行指針，這一過程稱為修剪。于是在修剪之后，我們通過HOT機制訪問數據便成了這樣：

1、通過索引元組找到舊元組的行指針1；

2、通過重定向的行指針1找到行指針2；

3、通過行指針2找到新元組tuple2。

這樣即使舊元組tuple1被清理掉也沒有影響了。

HOT對應的wal日志實現：

對于HOT的update操作，其wal日志中記錄的信息主要是由xl_heap_update結構存儲。

如果新的元組存儲在 block_id 為 0 的塊上，如果不是 XLOG_HEAP_HOT_UPDATE，那么舊的元組將會存儲在 block_id 為 1 的塊上。反之如果block_id 為 1 的塊沒有被使用，那么則認為是 XLOG_HEAP_HOT_UPDATE。

3、何時進行修剪

前面我們提到了，舊行的行指針會重定向到新行的行指針，這一過程稱之為修剪。那么什么時候會發生修剪呢？

一般來說，當我們執行select、update、insert、delete這些命令時均有可能觸發修剪，其觸發機制大致有兩種情況：

• 上一次進行update時無法在本page找到足夠的空間；
• 當前page上剩余空間小于fill-factor的值，最多小于10%

除此之外，當進行修剪時，還會選擇合適的時機進行死元組的清理，這一操作稱為碎片整理。碎片整理發生在當我們對元組進行檢索時發現空閑空間少于10%時，和修剪不同的是，碎片整理不會發生在insert時，因為該操作并不會檢索行。

相較于普通的vacuum操作，碎片清理并不涉及索引元組的清理，開銷相對于常規的清理要小很多，是通過PageRepairFragmentation函數來實現的。

這也是為什么HOT要求新舊元組需要在同一個page中，雖然從理論上來說我們可以將行指針的鏈表指向不同page，但是這樣我們便不能使用page-local的操作來進行碎片清理了。

4、HOT的不足

前面我們提到了HOT的前提條件之一就是：更新的列不能是索引列。需要注意，當更新的列是索引列時并不僅僅是會修改該列上的索引，整張表上所有的索引均會被修改。

例子：

創建測試表：

bill=# create table a(id int, c1 int, c2 int, c3 int);
CREATE TABLE
bill=# insert into a select generate_series(1,10), random()*100, random()*100, random()*100;
INSERT 0 10
bill=# create index idx_a_1 on a (id);
CREATE INDEX
bill=# create index idx_a_2 on a (c1);
CREATE INDEX
bill=# create index idx_a_3 on a (c2);
CREATE INDEX