PostgreSQL数据库在频繁更新场景下性能下降，这个问题困扰过不少团队。表面上看，可能是SQL写法或索引设计的问题，但深入一层就会发现，根源往往藏在更深的地方——MVCC（多版本并发控制）机制下的“死元组”堆积，以及负责清理它们的Autovacuum进程未能及时工作。这直接导致了查询变慢、磁盘空间膨胀、锁等待加剧等一系列连锁反应，严重时足以拖垮整张表的响应能力。
UPDATE在PostgreSQL里其实是“假删除+真插入”
理解性能问题的关键，在于认清PostgreSQL中UPDATE操作的本质。它并非我们通常理解的“原地修改”，而是一个“假删除”加上“真插入”的组合动作。具体来说，每次更新某一行时，数据库并不会直接覆盖旧数据，而是将旧行标记为“已死”（通过设置xmax字段），然后插入一个全新的行版本（带有新的xmin）。相应的索引条目也会同时指向新旧两个版本。
这意味着什么？
- 每一次更新，都会产生一个“死元组”和至少一个新的索引项。
- 这些死元组并不会立即释放物理空间，也不再参与正常的查询，但数据库在进行全表扫描或索引扫描时，仍然需要“跳过”它们，这无疑增加了I/O开销。
- 当死元组大量堆积时，受影响的不仅是
SELECT查询，后续的UPDATE、DELETE乃至VACUUM操作本身都会变慢。 - 可以算一笔账：如果一张表每天有几十万次的更新，一个月下来积累的死元组数量可能达到千万级别。而如果依赖默认的后台清理机制，很可能根本来不及处理。
autovacuum不是“开了就万事大吉”的后台服务
许多管理员认为，只要打开了Autovacuum就高枕无忧了，这其实是一个误区。默认配置下的Autovacuum触发条件相当保守：autovacuum_vacuum_scale_factor参数默认为0.2，意味着只有当死元组数量达到表总行数的20%时，才会触发清理；同时，autovacuum_vacuum_threshold默认为50，即最少要有50个死元组。
试想一张拥有500万行数据的表，按照默认设置，需要积累100万个死元组才会启动一次VACUUM。对于更新频繁的业务表来说，等到这个阈值，性能问题早已显现，为时已晚。
因此，针对高频更新的表进行参数调优是必要的：
- 显式降低单表阈值：可以直接对关键业务表调整参数，例如：
ALTER TABLE orders SET (autovacuum_vacuum_scale_factor = 0.05, autovacuum_vacuum_threshold = 5000);这样能在死元组积累到5%或5000个时就更早触发清理。 - 全局提升清理能力：调整
autovacuum_vacuum_cost_limit（默认200通常太低），例如设置为2000，可以让Autovacuum在单位时间内完成更多工作。 - 确保进程充足：确认
autovacuum = on，并根据系统负载适当增加autovacuum_max_workers（高负载环境建议设置为5或更高）。 - 谨慎使用VACUUM FULL：在业务高峰期间执行
VACUUM FULL会锁表，影响业务。可以考虑使用pg_repack这类在线重建工具来回收空间，避免长时间锁表。
死元组太多时，别只看n_dead_tup，还要看比例和年龄
监控时，pg_stat_user_tables视图中的n_dead_tup字段给出了死元组的绝对数量，但这只是一个方面。真正需要警惕的是死元组相对于活元组的比例，以及这些死元组的事务ID年龄。
一个长期未得到有效清理的表，可能死元组占比不高，但其中一些“元老级”的死元组已经存在了数月甚至更久。这些老旧的死元组不仅会干扰查询规划器（EXPLAIN ANALYZE）的成本估算，还会阻碍HOT（Heap-Only Tuple）更新的生效，后者本是一种优化特定更新场景、减少索引膨胀的机制。
因此，监控时需要多维度检查：
- 查看死元组比例：
SELECT relname, round(n_dead_tup::numeric/(n_live_tup+n_dead_tup),2) AS dead_ratio FROM pg_stat_user_tables WHERE n_live_tup > 0 ORDER BY dead_ratio DESC LIMIT 5; - 检查事务ID老化程度：
SELECT datname, age(datfrozenxid) FROM pg_database ORDER BY age(datfrozenxid) DESC;如果年龄超过1.5亿，就需要引起重视。 - 确认清理进程是否卡住：
SELECT * FROM pg_stat_progress_vacuum;查看是否有长时间运行的VACUUM进程。
还有一个极易被忽略的关键点：Autovacuum进程本身也可能被其他事务所阻塞。例如，一个长时间未提交的事务（比如开启了BEGIN; SELECT ... FOR UPDATE;却未结束），如果它持有了某些表的锁，那么Autovacuum就无法清理这些表中的死元组。死元组越积越多，又会进一步加剧性能问题，形成恶性循环。所以，定期检查pg_stat_activity视图中state = 'idle in transaction'的会话，并及时处理，其重要性有时甚至超过参数调优本身。
