什么是 MVCC？
MVCC（Multi-Version Concurrency Control，多版本并发控制）是 PostgreSQL 处理并发事务的核心机制。它的核心思想是：为每条数据保存多个历史版本，让读操作看到一致的快照，而不阻塞写操作；写操作创建新版本，而不覆盖旧版本。
这与传统数据库的锁机制有本质区别：
-
锁机制 ：读要等写完，写要等读完，高并发下性能急剧下降
-
MVCC：读写并行，互不等待，吞吐量显著提升
MVCC 的工作原理
1. 事务 ID（XID）
PostgreSQL 为每个事务分配一个递增的事务 ID（XID）。每行数据都隐藏着两个系统字段：
-
xmin：插入该行的事务 ID -
xmax：删除或更新该行的事务 ID（未删除时为 0）
2. 版本可见性判断
当一个事务读取数据时，PostgreSQL 根据以下规则判断某行是否可见：
-
xmin已提交 且xmax未提交或为 0 → 可见 -
xmin未提交 → 不可见 （其他事务的未提交数据） -
xmax已提交 → 不可见（该行已被删除）
3. 快照隔离
事务开始时，PostgreSQL 生成一份活跃事务快照，记录当前正在运行的所有事务 ID。读操作只能看到快照创建前已提交的数据，确保同一事务内多次读取结果一致（可重复读）。
实际效果：读写并行示例
sql
-- 事务 A（长查询，正在运行）
BEGIN;
SELECT COUNT(*) FROM orders WHERE status = 'pending';
-- 此时事务 B 插入新数据...
-- 事务 B（写入，不阻塞 A）
BEGIN;
INSERT INTO orders (status) VALUES ('pending');
COMMIT;
-- 事务 A 继续，看到的仍是快照时刻的数据，结果一致
COMMIT;事务 A 的读取不会被事务 B 的写入阻塞，两者并行执行。
MVCC 带来的优势
高并发写入
电商大促、金融交易等场景中，多个用户同时下单，每个写操作创建新版本，互不干扰，吞吐量远超锁机制。
时间点查询
PostgreSQL 支持 PITR（时间点恢复），可以回溯到任意历史时刻的数据状态，这正是基于 MVCC 的多版本特性实现的。
无锁读取
报表查询、数据导出等长时间读操作，不会因为业务写入而被阻塞，生产环境中无需担心"读锁住写"的问题。
MVCC 的代价：VACUUM
数据更新和删除只是创建新版本，旧版本数据（死行）会积累在磁盘上。PostgreSQL 通过 VACUUM 机制定期清理这些死行：
- Auto VACUUM：后台自动运行，无需手动干预
- VACUUM ANALYZE：清理死行同时更新统计信息，优化查询计划
- VACUUM FULL：完全重写表文件，释放磁盘空间（会锁表，谨慎使用）
sql
-- 查看表的死行数量
SELECT relname, n_dead_tup, n_live_tup
FROM pg_stat_user_tables
ORDER BY n_dead_tup DESC;与 MySQL 的对比
MySQL InnoDB 也实现了类 MVCC，但存在以下差异：
| 维度 | PostgreSQL MVCC | MySQL InnoDB |
|---|---|---|
| 实现位置 | 堆表直接存储多版本 | Undo Log 中存储旧版本 |
| 读取旧版本 | 直接读取堆中历史行 | 需重建 Undo 链 |
| 长事务影响 | 死行积累，需 VACUUM | Undo 空间膨胀 |
| 隔离级别默认值 | Read Committed | Repeatable Read |
总结
PostgreSQL 的 MVCC 是其在高并发场景下优于 MySQL 的核心原因。它让读写操作真正并行，为构建高吞吐、低延迟的数据密集型应用提供了坚实基础。理解 MVCC 的原理，是深入掌握 PostgreSQL 的关键一步。