PostgreSQL的MVCC机制下，UPDATE操作并不会原地修改数据行，而是生成一个新版本元组，并把旧版本标记为不可见。如果每次更新都同步修改所有关联索引，会产生大量重复的索引条目，既浪费磁盘空间，又拖慢更新速度。HOT（Heap Only Tuple）更新正是为了解决这一问题而设计：当新版本元组能放进原数据行所在的同一个数据页时，PostgreSQL可以只更新堆表内部的行指针链，而不触碰任何索引。启动HOT更新有一个铁律——被更新的列中不能包含任何索引列。

原因要从索引条目的结构说起。PostgreSQL的B-tree索引条目里存储的是索引列的值加上对应堆元组的物理位置（ctid，即页号和页内偏移）。如果索引列的值变了，旧索引条目对应的键值就不再指向正确的新元组，必须插入一个新索引条目来记录新键值和新位置。而如果索引列没变，索引条目中的键值保持不变，唯一可能变化的是ctid。但HOT更新的前提是新版本元组就在同一个页内，此时索引条目可以继续通过原来的ctid加行指针链找到最新版本，无需修改索引。因此，索引列不变是HOT更新能够跳过索引维护的根本原因。

HOT更新的存储结构与索引列不变的逻辑

要理解索引列不变的约束，先看一个普通更新的流程。假设有一张用户表，id是主键，email字段上建了唯一索引。执行UPDATE users SET email = 'new@ipipp.com' WHERE id = 1。PostgreSQL会先在堆表中插入一个新版本元组，同时要在email索引中删除旧的('old@ipipp.com', ctid_old)条目，再插入('new@ipipp.com', ctid_new)条目。哪怕新元组恰好和旧元组在同一个数据页，索引维护也无法避免，因为索引键值变了。

再来对比HOT更新。如果只更新一个非索引列，例如UPDATE users SET last_login = now() WHERE id = 1，而last_login不在任何索引中，那么新版本元组会尽可能放在旧元组所在的页面。旧元组被标记为已删除，并建立一条从旧元组到新元组的行指针链。原来的主键索引条目仍然指向旧元组的ctid，但通过行指针链，查询能够透明地跳到新版本。整个过程只修改了堆表页面，主键索引完全不需要改动。这就是HOT更新的核心收益：索引写放大从O(索引数量)降为0。

这里有一个容易混淆的点：不修改索引列并不保证一定能触发HOT更新，还需要新版本元组能放进旧元组所在的同一个8KB页面。如果页面剩余空间不足，或者新元组比旧元组大导致放不下，PostgreSQL就会退化为普通更新，即使索引列没变也会修改所有索引。但这属于另一个必要条件，索引列不变始终是前提条件中的第一道门槛。

索引列变更如何破坏HOT更新：实测对比

我们可以通过一个简单实验观察HOT更新与普通更新的行为差异。先创建一张带主键和额外索引的表，并插入一批数据：

CREATE TABLE hot_test (
    id SERIAL PRIMARY KEY,
    name TEXT NOT NULL,
    score INTEGER NOT NULL,
    updated_at TIMESTAMPTZ DEFAULT now()
);
CREATE INDEX idx_hot_test_score ON hot_test(score);
INSERT INTO hot_test (name, score)
SELECT 'user_' || g, (random() * 1000)::int
FROM generate_series(1, 10000) AS g;

初始数据插入后，先重置统计信息，然后执行一次只更新非索引列的操作：

SELECT pg_stat_reset();
UPDATE hot_test
SET updated_at = now()
WHERE id BETWEEN 1 AND 5000;
SELECT n_tup_upd, n_tup_hot_upd
FROM pg_stat_user_tables
WHERE relname = 'hot_test';

查询结果中，n_tup_upd是总更新行数，n_tup_hot_upd是实际发生HOT更新的行数。如果表上有足够的空闲空间，你会看到n_tup_hot_upd接近5000，说明大部分更新都走了HOT路径，索引没有被触碰。

接下来执行一次修改索引列的操作，把score字段的值增加1，score列上有索引idx_hot_test_score：

SELECT pg_stat_reset();
UPDATE hot_test
SET score = score + 1
WHERE id BETWEEN 1 AND 5000;
SELECT n_tup_upd, n_tup_hot_upd
FROM pg_stat_user_tables
WHERE relname = 'hot_test';

这一次，n_tup_hot_upd会显示为0，而n_tup_upd仍然为5000。因为score列的值变了，PostgreSQL必须维护idx_hot_test_score这个二级索引，同时主键索引虽然id没变，但ctid可能因为新元组位置不同而变化，所以也要更新。这就是索引列变更导致的索引写放大翻倍。

通过explain (analyze, buffers)可以更直观地看到索引维护开销。普通更新的执行计划中会出现对idx_hot_test_score的索引插入和删除操作，而HOT更新的执行计划中完全没有索引维护步骤。在高并发写入的场景下，这种差异会直接体现为更高的延迟和更多的WAL日志量。

HOT更新的其他必要条件和优化建议

除了索引列不变，HOT更新还必须满足以下条件：第一，新版本元组必须能放进旧元组所在的同一个数据页。PostgreSQL不会为了HOT更新跨页移动元组。如果页面已经填满，或者新元组比旧元组大，就会失去HOT机会。第二，新元组不能与旧元组之间存在其他活动事务可见的版本冲突，但这通常不影响判断。第三，系统配置中hot_standby_feedback等参数不影响HOT更新本身，但会影响清理旧版本的时机。

提高HOT更新命中率的最有效手段是合理设置表的fillfactor。默认fillfactor为100，意味着页面会被填满，后续更新基本无法在页内找到空间。对于频繁更新的表，可以将fillfactor设置为70或80，为新版本元组预留页面空间。例如：

ALTER TABLE hot_test SET (fillfactor = 80);

这样每个数据页在初始加载或vacuum后只填充80%，剩余20%空间专门留给HOT更新使用。虽然这会增加一些磁盘占用，但对于更新密集型的表，索引维护成本的降低往往远大于额外空间的代价。

另一个建议是避免在频繁变更的列上建立索引。很多开发者习惯给几乎每个查询条件列都加索引，但忽略了这些列在UPDATE中是否经常被修改。例如日志表中的status字段、用户表中的last_active_at字段，如果它们经常被更新，同时又被索引，那么每次更新都会导致索引写放大。可以考虑取消这类索引，或者改用部分索引、表达式索引等更精细的索引策略。

最后，定期执行VACUUM和ANALYZE也有助于维持HOT更新效率。VACUUM会清理页面中的死元组并回收空间，如果页面内的过期版本没有被及时清理，HOT更新所需的空闲空间会被挤占，导致新版本无法放入同一页面。使用pg_stat_user_tables监控n_tup_hot_upd与n_tup_upd的比率，可以判断当前表的HOT更新命中情况，当比率持续偏低时，应检查索引设计、fillfactor设置以及vacuum频率是否合理。

总结来说，索引列不变是PostgreSQL HOT更新的第一条硬性要求，它直接决定了更新操作能否跳过索引维护。理解这一约束，可以帮助我们在表结构设计和SQL编写中做出更明智的决策，从而获得更低的写放大和更高的更新吞吐。