PostgreSQL的UPDATE操作不覆盖旧值，而是通过MVCC机制保留历史版本。执行UPDATE时，原行被标记为过期（设置xmax），同时插入包含新数据的新版本行（设置xmin）。旧值仍存在于表中，直到VACUUM清理不再被任何事务需要的死元组。该设计依赖xmin、xmax和ctid等系统字段管理行版本，确保事务隔离性与读写并发性能，避免锁争用。但频繁更新会导致表膨胀，需依赖autovacuum回收空间。因此，合理配置autovacuum并避免长事务是维护性能的关键。
在PostgreSQL中，UPDATE操作不会立即覆盖旧值，这是由其多版本并发控制（MVCC）机制决定的。理解这一点需要了解PostgreSQL如何管理数据行的版本和存储结构。
PostgreSQL的MVCC与版本记录结构
PostgreSQL使用MVCC（Multi-Version Concurrency Control）来实现高并发下的事务隔离。每个数据行在物理上可以存在多个版本，新旧版本共存，直到系统确认没有事务再需要旧版本为止。
当你执行一个UPDATE语句时，PostgreSQL并不是直接修改原有行数据，而是：
- 将原行标记为“已过期”（通过设置xmax字段）
- 插入一条新的行版本，包含更新后的数据（并设置xmin为当前事务ID）
这意味着，旧值并没有被覆盖或删除，而是在同一张表中作为历史版本保留下来，直到被VACUUM进程清理。
行版本的系统字段
每一行记录都包含隐藏的系统字段，用于支持MVCC：
- xmin：创建该行版本的事务ID
- xmax：删除或更新该行的事务ID（初始为0）
- ctid：行在表中的物理位置（块号+行号）
当执行UPDATE时，原行的xmax被设为当前事务ID，表示该版本对之后启动的事务不可见；新行的xmin设为当前事务ID，表示从该事务开始可见。
为什么这样设计？
这种不覆盖旧值的设计带来了几个关键优势：
- 读操作无需等待写操作完成，反之亦然，提升并发性能
- 每个事务看到的数据一致性由其快照决定，避免脏读、不可重复读等问题
- 崩溃恢复和备份更安全，因为历史状态可追溯
但代价是表空间会随频繁更新而膨胀，需要定期运行VACUUM（或autovacuum）回收 dead tuple 占用的空间。
实际影响与处理建议
开发者和DBA应注意：
- 频繁UPDATE大表可能导致表膨胀，监控bloat情况
- 长时间运行的事务会阻止VACUUM清理旧版本，应避免
- 可以通过pg_stat_user_tables查看n_tup_del、n_tup_upd等统计信息，判断更新频率
- 启用并合理配置autovacuum至关重要
基本上就这些。PostgreSQL的UPDATE不覆盖旧值，是为了服务MVCC机制，保障事务隔离和系统性能，背后是一套完整的版本管理逻辑。
