先聊一个很多人在优化业务库时都会遇到的场景一张大表频繁执行 UPDATE索引也不复杂但表越跑越大磁盘占用蹭蹭往上涨查询却不见变快。你下意识想加索引、调参数、甚至想迁移到其他数据库却没意识到问题可能出在“索引更新”这件事本身。PostgreSQL 里有一个不太高调、但极其实用的机制能大幅缓解这个问题它叫堆内元组更新英文简称 HOTHeap-Only Tuple。这篇文章就把 HOT 的来龙去脉、核心原理、实操验证方法和避坑经验一次性讲透。HOT 解决的核心痛点是“UPDATE 时所有索引都要跟着更新”的开销。对熟悉 MySQL InnoDB 或 SQL Server 的人而言PostgreSQL 的 MVCC 实现方式完全不同它会把旧版本和新版本都放在堆表里索引条目需要指向对应版本。如果每次 UPDATE 都让所有索引跟着改写放大非常夸张索引膨胀、插入性能下降都是这么来的。HOT 直接砍掉了大部分场景下的索引维护工作代价很小收益却相当可观。这篇文章适合数据库运维、开发以及所有想把 PostgreSQL 用得更明白的人看完你至少能回答这几个问题HOT 为什么省索引更新怎么确认 HOT 在线上生效什么场景会让 HOT 失效1. HOT 到底解决了什么问题1.1 索引更新的成本到底有多大要理解 HOT必须先从 PostgreSQL 的 UPDATE 机制说起。很多人学 MVCC 时只记住了“读不阻塞写、写不阻塞读”却忽略了写放大问题。在 PostgreSQL 里一次 UPDATE 的完整流程是这样的新的版本行被插入到当前数据页也可能是新的页旧版本行保留在原位置然后通过行头部的 xmin/xmax 字段形成版本链。如果这张表上有索引索引条目需要指向某个具体版本。为了让查询能通过索引快速找到最新版本UPDATE 通常会让索引指向新版本的位置。这就引出了核心成本如果表上有 5 个索引一次 UPDATE 可能需要同时修改 5 个索引结构。尽管 PostgreSQL 的索引更新做了很多优化比如某些情况下可以复用索引页内的空间但从 B-Tree 结构上讲这依然意味着更多的页面分裂、更多的页面写入、更大的 WAL 日志量。我在实际运维中见过一个比较极端的例子一张表有 7 个索引业务逻辑是高频小字段更新结果索引所在的表空间比堆表本身还大几倍磁盘压力全在索引写放大上。我的看法是索引更新问题往往被“加索引优化查询”的光环掩盖了。大家总习惯从查询角度评估索引价值却很少有人系统性评估索引对写入路径的影响。写放大不只是一次 UPDATE 多写几个页面的问题它还意味着更需要频繁做 VACUUM意味着索引树结构更容易膨胀意味着 autovacuum 的负担成倍增加。HOT 的价值就在于在它能生效的场景里这些开销全部被省掉。1.2 传统场景下的“死元组膨胀”现象PostgreSQL 的 MVCC 靠保留旧版本实现快照隔离代价是“死元组”必须等待 VACUUM 回收。如果一张表的更新频率远高于 VACUUM 清理频率表就会膨胀。膨胀的堆表不仅浪费磁盘更严重的是让顺序扫描变慢、缓存命中率下降整个实例的内存和 IO 都被无用的历史版本占住。索引也有膨胀问题。索引条目会保留指向旧版本的指针即便旧元组在堆表里已经被标记为不可见索引里的条目仍然存在直到 VACUUM 专门做索引清理。这是一个双重负担堆表要回收旧版本索引页也要回收旧条目。如果 UPDATE 频繁且索引列根本没变这些索引更新实际上是纯粹的浪费——索引指向的目标虽然变了但索引键值没有变。HOT 正是利用了这个观察只要索引键值不变索引根本不需要跟着版本迁移走。1.3 一句话说清 HOT 的取舍逻辑HOT 的核心思路可以概括为如果 UPDATE 没有改变任何索引键列而且新版本可以放到与旧版本同一个数据页内那就让索引继续指向旧版本的位置另外在新版本行头部用 t_ctid 字段串起一条“只在堆内移动”的版本链。查询时通过索引找到旧版本再沿着版本链找到新版本。这个过程里索引条目完全不需要修改。省掉了索引更新也就省掉了一系列连锁成本B-Tree 页面的写入、可能的页分裂、WAL 日志的增加、VACUUM 对索引的清理。代价是什么代价是后续通过索引访问时多了一步“沿着版本链向后找”而且要求新版本必须和旧版本挤在同一个页面里。如果放不下就退化为普通更新。说白了HOT 是一种典型的空间换时间再换空间的思路用一个指针链的小成本换取索引维护的大成本消失。2. HOT 的核心原理拆解2.1 从一次 UPDATE 说起版本链是怎么建立的在 PostgreSQL 表结构里每个元组头部有一个 t_ctid 字段正常情况下它指向这个元组自己。如果在同一页面内发生了 HOT 更新旧元组的 t_ctid 会指向新元组的实际位置如果新元组在另一个页面旧元组 t_ctid 指向的位置跨越了页面边界这种就不能算 HOT而是普通更新。为什么要限制在同一个页面内这涉及索引扫描的语义安全。当一个 HOT 链足够长时索引条目只指向链首查询必须沿着 t_ctid 逐步找到链尾也就是最新版本。如果允许跨页面链查询时可能需要读取多个页面而且页面回收的顺序会变得非常复杂。限制在同一页面内HOT 链的所有成员都共享同一个缓冲池页面访问链上的任何版本都不会产生额外的随机 IO。版本链的存在也让 VACUUM 的清理工作变得更加明显。普通 UPDATE 产生的旧版本可以直接判断为死元组HOT 链上的中间版本则不能随便删因为它们可能仍然被某些旧快照引用。这就是 HOT 机制里“剪枝pruning”的由来下面单独展开。2.2 HOT 怎么做到“不更新索引”需要明确一个容易混淆的点HOT 并不是完全不做任何索引相关操作而是省去了“在 UPDATE 时修改索引条目”这一步。具体来说UPDATE 执行前会判断一个关键条件新版本涉及的索引键列值和旧版本相比有没有变化。如果索引列的值变了HOT 无法生效因为索引键值本身已经无法复用必须修改索引条目甚至可能需要插入新的索引项。如果所有索引列的值都没变那么索引条目指向链首即可因为无论链上有多少个版本它们最终指向的行在索引键维度上的语义是相同的。注意“索引键列”这个概念。一个索引如果是由多个列组成的只要其中任何一个列被更新整个索引键就算变了HOT 就会失效如果更新的列是普通字段不涉及任何索引键则不会影响该索引的复用。一张表有多个索引时HOT 生效的条件是所有索引的键列都不能被更新这就是为什么业务设计中如果频繁 UPDATE 某一个字段却在该字段上建了索引那么 HOT 基本帮不上忙。2.3 剪枝与清理真正的黑科技在这里HOT 的精妙之处在于它把“索引清理”的时机从 UPDATE 时延迟到了 VACUUM 时并且在中间加入了一个“剪枝pruning”动作。剪枝指的是某个 HOT 链上如果链中间的元组已经不再被任何活动事务可见就可以提前把它们清理掉不必等 VACUUM 全表扫描。举一个具体流程表 t 上有一行数据第一次 HOT 更新产生版本 A 和版本 B旧的索引条目指向 A。之后又发生一次 HOT 更新产生版本 B 和版本 C。此时 VACUUM 或某些特殊操作发现 B 版本已经没有人可见那么剪枝会移除 B同时让 A 的 t_ctid 直接指向 C也就是把链缩短到 A → C。为什么这样做有好处因为索引扫描时从链首到链尾需要遍历的中间节点越少访问最新版本的开销就越低。这个“缩短链”的操作不需要触碰索引条目所以剪枝的成本极低。只有当链首元组本身也被标记为不可见时才需要真正去索引里清理对应的条目这一步通常发生在 VACUUM 过程中。总结来说HOT 把原本每次 UPDATE 的索引维护成本降级成了少数情况下的索引清理成本并且把大部分中间版本回收用剪枝完成收益就在这一层层细节里。2.4 HOT 的判定条件哪些场景能用哪些不能用官方文档里的表述很简单但实际生效条件里有几个容易被忽略的细节更新的索引键列值不变。只要有一个索引的键列被更新HOT 就失效。注意是“索引键列”不是“索引表达式”。如果索引是表达式的形式比如 lower(email)那么只要表达式结果不变即使原始字段变了也可能还能用但这种情况极少见一般不建议依赖。新版本必须和旧版本在同一数据页并且新版本能插入到该页。由于页面内空间有限如果该页面已经满了HOT 同样失效。这也是为什么填充因子fillfactor设置会对 HOT 命中率有直接影响。系统必须启用 HOT。实际上 PostgreSQL 默认就支持 HOT不需要额外打开任何开关但在一些特殊情况下如复制中的级联系统自动行为可能比想象得更保守。实际线上最可惜的失效场景往往不是“索引列被更新”而是页面没有空间。业务表如果所有页面都被填满那每次 HOT 更新都无法找到插入位置直接退化为普通更新。要解决这个问题基本思路就是调小 fillfactor给 HOT 链留空间这个细节后面会有专门一节。3. 怎么确认 HOT 在线上生效3 个实测手段3.1 通过统计视图看 HOT 命中率判断 HOT 是否真的在干活最直接的手段是查看 PostgreSQL 的统计视图。pg_stat_user_tables 和 pg_stat_all_tables 里有两个关键字段n_tup_upd 表示该表累计触发 UPDATE 的行数n_tup_hot_upd 表示其中由 HOT 机制完成的更新行数。两者相除就是 HOT 命中率。SELECT relname, n_tup_upd, n_tup_hot_upd, round(100.0 * n_tup_hot_upd / NULLIF(n_tup_upd, 0), 2) AS hot_ratio FROM pg_stat_user_tables ORDER BY n_tup_upd DESC;我自己的习惯是把这个查询放到监控脚本里按小时看趋势。命中率长期低于 50%说明 HOT 的收益没有充分释放需要进一步排查表里索引列更新频率和页面空间情况。需要提醒一下统计计数器是从上次统计重置之后累计的如果业务表刚做过大量数据迁移或 VACUUM FULLn_tup_upd 可能从 0 重新计这时候的命中率参考意义不大最好等业务跑一段时间再看。3.2 通过 pageinspect 看页面真相统计视图只是一个间接指标真要验证 HOT 链是不是真的存在可以用 PostgreSQL 自带的扩展 pageinspect。它允许你直接查看数据页内部的元组头部信息t_infomask 里有一个标志位 HEAP_HOT_UPDATED标识这个元组是否是由 HOT 更新产生的。还有一个 HEAP_ONLY_TUPLE 标志位标识这个元组是否只能通过 HOT 链访问。操作很简单先安装扩展并找到对应的表文件位置再用 heap_page_items 函数查看页面元组。该方法适用于你想确认某张特定表的物理结构是否符合预期比如怀疑 HOT 链过长或剪枝没有生效时直接看页面内部是最有说服力的。CREATE EXTENSION IF NOT EXISTS pageinspect; SELECT t_ctid, t_infomask, (t_infomask 128)::int AS hot_updated, (t_infomask 32)::int AS only_tuple FROM heap_page_items(get_raw_page(public.test_table, 0));需要注意的是HEAP_HOT_UPDATED 标志位的数值可能随 PostgreSQL 版本变化我这里写的是基于常见版本的位掩码实际操作前最好先查自己版本的定义。这种东西不需要经常用但在调优 HOT 相关问题时它是能一锤定音的证据。3.3 通过计划分析验证执行路径第三个手段是行为层面的验证。如果 HOT 生效意味着查询走索引时需要进行版本链的追踪但这并不会出现在执行计划里。你能看到的只是索引扫描正常工作。所以性能测试更实用在相同数据量和负载下分别测试 HOT 命中率高和命中率低的场景观察 UPDATE 的 TPS、WAL 生成量、索引页的变更量。如果几个指标的差距非常明显说明 HOT 确实对写路径产生了实质性影响。我实测过的对比场景一张数据量约 5000 万行的表表上有 3 个索引更新字段为普通列。将 fillfactor 从 100 调至 70 后HOT 命中率从不到 10% 提升到 60% 以上同一压力条件下的 UPDATE TPS 提升了约 30%WAL 写入量下降更明显。不过要说明这个数据来自我当时的特定环境不同机器、不同数据分布结果会完全不同但方向性是没有问题的。4. HOT 失效与性能陷阱避坑指南4.1 常见失效场景盘点理论上 HOT 的触发条件不难满足但线上真实环境里失效场景非常多而且有些坑隐藏得很深。第一个经典坑是“更新主键”。主键是唯一索引一旦更新主键索引键列自然变化HOT 直接失效。有些业务设计里会把主键当作业务键用时不时调整主键值这种表基本和 HOT 无缘。第二个坑是“更新被索引的冗余列”。比如一张表有订单状态字段 status业务代码里经常把 status 从 1 改成 2。如果你在 status 上建了索引而业务逻辑又恰恰频繁更新它那么 HOT 对这个字段无能为力。这时候要么去掉这个索引改用其他方式优化查询要么把该字段从索引中移除让 HOT 有机会在其他更新场景中生效。第三个坑是“页面已满”。这个不那么直观。PostgreSQL 默认 fillfactor 为 100意味着每个页面尽量填满。HOT 更新虽然不移动索引但新版本必须插入同一页面。如果页面已经填满数据库只能把新版本放到其他页面此时 HOT 直接失效。这种情况在高并发更新场景下非常普遍表现为 HOT 命中率突然下掉。第四个坑是“链首元组被标记为不可见时的不利连锁”。当旧版本不能被剪枝清除时VACUUM 会尝试做索引清理。如果表上有大量这样的链且索引清理跟不上索引膨胀问题还是会回来。HOT 不是银弹它只是大幅减少了索引维护频率并不能彻底消除。4.2 fillfactor 该怎么配fillfactor 是 PostgreSQL 中少数几个直接影响 HOT 命中率的表级参数。它表示每个页面最多填充多少比例剩余空间保留给未来的 HOT 更新。默认值是 100相当于完全不预留空间。要让 HOT 发挥效果通常需要调低这个值。但 fillfactor 不能盲目调。调太低页面使用率下降同样数据量需要更多页面顺序扫描和缓存命中都会受影响调太高则 HOT 命中率上不来写路径优化失效。我的经验是对频繁 UPDATE 的业务表可以先从 70 开始尝试如果 SELECT 量大但 UPDATE 量不大保持 85 到 90 可能更平衡数据归档表这类几乎只插入不更新的表保持 100 反而最优。修改 fillfactor 不需要重写表数据只需一条 DDLALTER TABLE public.test_table SET (fillfactor 70);不过要明确这个参数只影响后续的页面分配和 INSERT 行为已有页面不会自动重新整理。要彻底应用让新设置对存量页面生效需要执行 VACUUM FULL 或重组表。HOT 本身不会帮你重写旧页面所以在调整后需要计划一个维护窗口确保表能被重新整理。4.3 表膨胀管理HOT 不是万能药表膨胀是 PostgreSQL 运维的老话题HOT 能在很大程度上减少“堆表膨胀”中由索引更新引发的那一部分但它无法阻止所有膨胀。即使 HOT 命中率很高频繁的 UPDATE 仍然会产生大量死元组只是回收成本降低了。如果 autovacuum 配置不当膨胀依然会持续积累。我有一个专门处理膨胀的例行方案每周定期检查 pg_class.relpages 和实际表大小的比例如果膨胀率超过 1.5 倍就先调 autovacuum 参数比如减小 autovacuum_vacuum_scale_factor或者给特定表单独配置更高的清理频率。膨胀比较严重的表再做一次 VACUUM FULL。HOT 的价值在于当我调优完成后膨胀反弹的速度慢了很多低频的 VACUUM FULL 就能把整体空间维持在可控水平。还要提醒一个容易被忽视的点HOT 省的是 UPDATE 的索引维护但 INSERT 产生的索引条目仍然要写。如果一张表本身更新比例不高但 INSERT 量极大调 low fillfactor 反而会影响插入性能因为每个页面的可用空间变小页面分裂会更频繁。所以 HOT 优化的前提是确认业务以 UPDATE 为主导再动手调参。5. 常见问题排查实录5.1 为什么 HOT 命中率上不去先别急着调 fillfactor按以下顺序排查会更快检查业务 SQL 里实际更新的字段有哪些是否覆盖了表上的索引键列。很多人以为“没改动主键就没事”但复合索引里任何一列变化都会让 HOT 失效。查看表的 fillfactor 设置如果为 100大概率页面空间不足。用 pg_stat_user_tables 对比 n_tup_upd 和 n_tup_hot_upd如果一个表自上次统计以来 HOT 命中率几乎为 0而它确实频繁更新非索引列那么极可能是页面空间满所致。考虑版本因素。过老的 PostgreSQL 版本对 HOT 的优化不够完善如果业务允许尽量使用较新版本。曾经有一个典型的极端案例某团队反馈一张配置表的 HOT 命中率接近 100%但业务日志显示它并没有频繁 UPDATE。后来发现这张表的数据量很小所有行都在少数几个页面内页面空间充足所以几乎每次 UPDATE 都满足 HOT 条件。这其实说明了一个道理命中率本身不代表性能收益要结合表规模和写入量综合判断。5.2 HOT 链过长会造成什么问题HOT 链过长最直接的问题是索引扫描时从链首遍历到链尾的代价变大。如果一条链上堆积了几十个版本即使它们在同一个页面里也需要逐次比较事务可见性并跳转。虽然相比索引更新这个代价很小但当查询量很大时累积开销依然值得关注。为什么会出现长链通常是因为更新频率极高而 VACUUM 和剪枝没有及时把中间版本清掉。PostgreSQL 的剪枝时机并非每次访问都做它依赖于特定的触发条件。如果业务表更新极频繁一个页面里同一行在短时间内不断 HOT 更新链就可能拉长。想改善可以降低 autovacuum 的触发阈值让 VACUUM 更频繁地进来做剪枝。我通常用以下查询识别长链风险虽然不是百分百精确但能定位到疑似表SELECT relname, n_live_tup, n_dead_tup, last_vacuum, last_autovacuum FROM pg_stat_user_tables ORDER BY n_dead_tup DESC LIMIT 20;如果看到 n_dead_tup 长期居高不下就要考虑调整 autovacuum 参数了。5.3 一条实用的优化套路最后分享一个我在某项目上实际用过的组合拳整体步骤可以复用到大部分高频更新场景第一步先停止盲目加索引把表上所有索引列和 UPDATE 语句的 SET 字段列出来对照。第二步把频繁更新的字段上建立的、收益又不大的索引删除用只覆盖核心查询字段的复合索引替代。第三步将表的 fillfactor 调低并配合 VACUUM FULL 重建页面给 HOT 留出操作空间。第四步重新观察 n_tup_hot_upd 比例和 WAL 生成量确认是否改善如果改善不明显再考虑调整 autovacuum 阈值。这套流程做完之后我的感受是HOT 不是一个需要全天候盯着监控的“新特性”它更像是一个需要你在表设计阶段就想清楚的因素。设计表时就知道这个字段高频更新、那个索引收益不大后续能少踩很多坑。回到开头那个高频更新导致表膨胀的问题。按这个思路排查处理之后那套系统的表膨胀基本稳定下来索引维护量大幅下降VACUUM 频率也没那么紧张了。我个人的体会是PostgreSQL 的性能调优里很多优化点其实都在“理解它为什么不这么干”上。HOT 机制的每一处限制背后都是安全性、并发控制和物理存储之间的权衡。真正理解了这些权衡遇到新问题时会更容易找到正确的调整方向。如果你手上也有一张频繁 UPDATE 的表不妨先看一下统计视图里的 HOT 命中率。如果偏低对照本文的失效场景排查大概率能发现一些被忽略的设计问题。这就是基础机制带来的收益它不是炫技而是让数据库在正确的工作负载下自动走最优路径。