第 1 章 · PostgreSQL 是什么 & 为什么火

三个交互演示：① PG vs MySQL 进程/线程模型对比 · ② PG Postmaster 架构 · ③ 1000+ 扩展生态地图

同时来 6 个客户端连接，看看两种模型怎么处理

左边 PG 走 fork() 多进程；右边 MySQL 走 pthread_create() 多线程。点「+ 新连接」看动画效果，点「💀 模拟崩溃」看崩溃隔离差异：

🐘 PostgreSQL（多进程）每连接 fork 一个 OS 进程

Postmaster (PID 1001) — listen *:5432

⬛ Shared Buffers (共享内存) ⬛

当前连接：0 Backend 进程：0 实例存活：✓ 健康 ~ 内存占用：0 MB

🐬 MySQL（多线程）每连接 1 个进程内线程

mysqld 主进程 (PID 2001) — listen *:3306

⬛ Buffer Pool (共享内存) ⬛

当前连接：0 线程数：0 实例存活：✓ 健康 ~ 内存占用：0 MB

关键差异： ① 内存：PG 每连接 ~10 MB，MySQL 每连接 ~256 KB； ② 崩溃：PG 一个 backend 死了不影响别人，MySQL 一个线程踩坏内存可能整个 mysqld 都挂； ③ 启动开销：fork 比 pthread_create 慢 10-100 倍 → PG 必须配 PgBouncer 连接池。

面试要点： "PG 为什么要连接池？" → 多进程模型下连接成本极高，连接数过万必然 OOM；PgBouncer 在 transaction 模式下能用 10 个真实 PG 连接服务上千应用层短连接。

从客户端连接到 Backend 进程的完整生命周期

点击左侧任一客户端发起一个连接，看 Postmaster 如何 fork 一个新的 backend 来服务它。注意右下角的 4 个常驻后台进程（WAL Writer / Auto Vacuum / BgWriter / Checkpointer）：

客户端 (psql / app)

PostgreSQL 实例

Postmaster (主进程) · 监听 0.0.0.0:5432

↓ accept() + fork()

还没有 backend，点左侧客户端开始连接 →

⬛ Shared Buffers / WAL Buffers / 锁表 / Stats Collector ⬛

walwriter autovacuum launcher bgwriter checkpointer stats collector

[init]Postmaster 启动完毕，等待连接...

PostgreSQL 扩展生态地图

用 CREATE EXTENSION xxx; 一行命令就能装上的「能力包」。点击卡片看用法、它替代了什么独立产品：

📊 PG vs MySQL 关键能力对比速查

能力	PostgreSQL	MySQL
JSON 索引	✅ JSONB + GIN 索引	⚠ JSON 不可索引
数组类型	✅ 原生 + GIN	❌ 不支持
地理	✅ PostGIS（业界标杆）	⚠ 仅基础 GEOMETRY
向量检索	✅ pgvector	⚠ 8.4+ 实验
事务 DDL	✅ 可回滚	❌ 隐式提交
窗口函数	✅ 完整	✅ 8.0+ 完整
CTE 递归	✅ 完整 + RETURNING	✅ 8.0+
UPSERT	✅ ON CONFLICT	✅ ON DUPLICATE KEY
逻辑复制	✅ 内置 pub/sub	⚠ binlog 工具链复杂
分区	✅ 声明式 + 裁剪	✅ 但功能较弱