根本原因是mvcc机制下死元组堆积且autovacuum未及时回收，导致查询变慢、磁盘膨胀、锁等待加剧；update本质是“假删除+真插入”，每更新一次产生一个死元组和至少一个索引项；默认autovacuum触发阈值过于保守，需调低scale_factor和threshold，并提升cost_limit、worker数，同时避免长事务阻塞清理。
PostgreSQL频繁更新导致性能下降，根本原因不在SQL写法或索引缺失，而在于MVCC机制下死元组持续堆积，又没被Autovacuum及时回收——这会让查询变慢、磁盘膨胀、锁等待加剧，甚至拖垮整个表的响应。
UPDATE在PostgreSQL里其实是“假删除+真插入”
每次UPDATE某一行，PostgreSQL不会原地修改，而是把旧行标记为“已死”（设置xmax），再插入一个新版本（带新xmin）。索引也会同时指向新旧两个版本。这意味着：
- 每更新1次，就多1个死元组 + 至少1个索引项
- 死元组不释放空间，也不参与查询，但扫描时必须跳过它们
- 大量死元组会让
SELECT、UPDATE、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); - 全局调高清理能力：
ALTER SYSTEM SET autovacuum_vacuum_cost_limit = 2000;（默认200，太低） - 确认
autovacuum = on且autovacuum_max_workers≥ 3（高负载建议设5） - 避免在业务高峰执行
VACUUM FULL——它会锁表，改用pg_repack在线重建
死元组太多时，别只看n_dead_tup，还要看比例和年龄
pg_stat_user_tables里的n_dead_tup只是绝对数量，真正危险的是dead_ratio和事务ID年龄。一个长期未清理的表，可能死元组占比不到10%，但其中很多已存在数月——这些老死元组会拖慢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'的会话，比调参数还重要。
