PostgreSQL 深度剖析：从 MVCC 到执行器、从索引到复制与恢复

0. 为什么选 Postgres？

PostgreSQL 是“通用关系数据库里的瑞士军刀”。它既是严格的 ACID 事务数据库（OLTP），又能靠扩展生态（FDW、索引族、存储过程、流复制、插件）向 HTAP/地理/时序/JSON 文档场景伸展。真正的优势在于两点：可解释性（计划器透明、调参可控）与 可塑性（扩展点多）。

---

1) 事务与并发：MVCC、快照与可见性

1.1 MVCC 的本质

Postgres 不会就地更新行——每次 UPDATE 会生成一个新版本（元组），旧版本仍留在表中等着 VACUUM 清理。每个版本带有 (xmin, xmax) 两个事务 ID；可见性取决于当前事务的快照（包含了哪些事务已提交/未提交）。

• 读取：只读到对自己“可见”的版本（快照一致）。

• 写入：在新版本上写，尽量避免读写冲突，提升并发性。

1.2 可见性/快照与隔离级别

隔离级别从低到高：READ COMMITTED（默认）→ REPEATABLE READ → SERIALIZABLE。

• READ COMMITTED：每条语句拿一次快照；同一事务中后续语句可能看到前一条刚提交的更改。

• REPEATABLE READ：整个事务使用同一个快照，避免“不可重复读”。

• SERIALIZABLE：通过可串行化快照隔离（SSI）检测事务间的危险结构并冲突回滚，确保结果等价于串行执行。

建议：默认保持 READ COMMITTED；需要强一致分页/统计时用 REPEATABLE READ；银行级转账之类用 SERIALIZABLE，但要预期冲突回滚率上升。

---

2) VACUUM、Autovacuum 与表膨胀

2.1 为什么需要 VACUUM？

旧版本不能永远躺在表里，否则：

• 表膨胀（bloat）：扫描更多页，I/O 增加，缓存命中率下降。

• XID wraparound：事务 ID 是 32 位计数器，会回绕；需要冻结（freeze）早期版本的事务号，避免数据“看起来从未来来”。

2.2 Autovacuum 的调优思路

核心不是“开没开”，而是频率/强度是否跟得上写入速度。关键参数（只讲思路）：

• autovacuum_vacuum_scale_factor / autovacuum_analyze_scale_factor：按表规模比例触发，写入密集表可砍小（如 0.1→0.02）。

• autovacuum_vacuum_cost_limit / cost_delay：成本控制，IO 紧张时加大 delay。

• autovacuum_naptime：全局轮询间隔。

• 大表热点更新：降低 FILLFACTOR（比如 90→80），争取 HOT 更新