postgresql的update通常破坏索引项是因为采用“删除旧行+插入新行”机制，导致旧索引项指向已死亡元组，需额外检查xmax拖慢性能；hot更新可避免此问题，但须同时满足不修改索引列、新行同页存储、目标页有足够vacuum标记空闲空间三个条件。
PostgreSQL的UPDATE为什么通常会破坏索引项
PostgreSQL 的 UPDATE 默认不是原地修改，而是“删除旧行 + 插入新行”的逻辑。即使只改一个字段，只要新值导致 tuple 大小变化或需跨页存储，就会生成新 ctid，旧索引项指向的物理位置就失效了——索引本身没被重建，但其中大量条目变成“指向已死亡元组”的无效引用，后续查询仍要检查 xmax 和事务状态，拖慢性能。
HOT更新触发的三个硬性条件
HOT（Heap-Only Tuple）更新能避免索引重建，但必须同时满足：
-
UPDATE不修改任何被任意索引包含的列（包括主键、唯一约束、普通 B-tree 索引的INCLUDE列） - 新 tuple 必须能存放在与旧 tuple 相同的数据页内（受
fillfactor和页内空闲空间限制） - 目标页上存在足够多的
free space map记录（即该页曾被VACUUM清理过，标记出可重用空间）
缺一不可。比如给 name VARCHAR(50) 字段追加 2 字符，若所在页已满且未被 VACUUM 扫过，哪怕没建索引也会 fallback 到常规更新。
如何验证某次UPDATE是否走HOT路径
最直接方式是查系统视图：pg_stat_all_tables 中的 n_tup_hot_upd 计数器。但要注意它统计的是“成功 HOT 更新次数”，不是实时判断单条语句。更准的做法是：
- 开启
log_statement = 'mod'+log_min_duration_statement = 0，在日志里搜UPDATE后跟HOT关键字（需编译时启用--enable-debug或使用 debug 版本） - 用
pageinspect扩展查看具体页：先SELECT ctid, xmin, xmax FROM tbl WHERE ...定位 tuple，再SELECT * FROM heap_page_item_attrs('tbl'::regclass, 0)查该页所有 item，观察是否有多个ctid指向同一页但不同lp_off，且xmax = 0或为已提交事务 ID
别依赖 EXPLAIN —— 它从不显示 HOT 相关信息。
让HOT更常生效的实操配置建议
HOT 不是开关，是结果。要提升命中率，得从数据写入阶段干预：
- 建表时设合理
FILLFACTOR（如70），给后续更新留空隙；但别设太低，否则浪费磁盘和缓存 - 对频繁更新的表，定期
VACUUM（非VACUUM FULL），确保 free space map 可用；自动 vacuum 参数vacuum_cost_delay和autovacuum_vacuum_scale_factor要调得激进些 - 避免在经常更新的列上建索引；如果必须索引，考虑用函数索引（如
CREATE INDEX ON tbl ((status = 'active'))）替代直接索引字段值
HOT 的边界很脆：一次大字段更新、一次未及时 vacuum、一个无意中加上的索引，都可能让整张表的更新效率断崖下跌。监控 n_tup_hot_upd / n_tup_upd 比值比看索引大小重要得多。
