数据库选型
选型的核心不是比谁强，而是匹配数据形态。本篇以 PostgreSQL vs MySQL 的对比为核心，因为这是后端面试最常见的选型题。
PostgreSQL vs MySQL
| 维度 | PostgreSQL | MySQL |
|---|---|---|
| 存储模型 | 堆表 + CTID | 聚簇索引组织表 |
| MVCC | 版本留在堆里，VACUUM 清理 | undo log，purge 清理 |
| 默认隔离级别 | 读已提交 | 可重复读 |
| RR 防幻读 | 不防（无间隙锁），可串行化用 SSI | 防（临键锁） |
| 日志体系 | 一套 WAL | redo + undo + binlog，两阶段提交 |
| 索引类型 | B-tree/GiST/GIN/BRIN/Hash | B+树/哈希/全文 |
| 扩展生态 | PostGIS/pgvector/FDW/分区 | 分区弱，扩展少 |
| 复制 | 流复制 + 逻辑复制 + Patroni | 主从 binlog + 半同步 |
| 高可用 | Patroni（成熟事实标准） | MHA/Orchestrator 等，生态成熟 |
| 运维 | VACUUM 是必修课 | 相对简单 |
| 并发模型 | 多进程，连接开销大要连接池 | 线程模型，连接轻量 |
怎么选：
- 数据完整性和复杂查询优先（金融、GIS、JSON 灵活查询、分析）→ PostgreSQL
- 团队 MySQL 经验深厚、生态工具成熟、读多写少的互联网业务 → MySQL
- 需要全文、空间、向量多种能力 → PostgreSQL（一个库顶三个）
- 需要 VACUUM 和长事务治理经验，运维投入不足 → MySQL 更省心
一个务实结论：两者都是优秀的关系库，选型的决定因素通常是团队熟悉度和业务特性，而不是纸面对比。新项目功能需求多（JSONB、分区、扩展）选 PG 的趋势明显。
其他存储的定位
| 存储 | 定位 | 典型场景 |
|---|---|---|
| Redis | 缓存层，不是主存储 | 热点缓存、计数器、分布式锁 |
| MongoDB | 灵活 Schema 文档库 | 内容、快速迭代，事务能力弱于关系库 |
| Elasticsearch | 检索和分析引擎 | 全文搜索、日志 |
| 向量库 | RAG 场景 | 向量检索，pgvector 是轻量入口 |
组合是常态
生产架构几乎都是组合：MySQL 或 PG 做主库，Redis 做缓存，ES 做检索，pgvector 或专用向量库做 RAG。同步链路（binlog/WAL 监听、双写、MQ）是面试加分点。
面试追问
- PG 和 MySQL 最本质的区别？ 存储模型和 MVCC 机制：堆表加 VACUUM 对比聚簇索引加 undo log。其余差异（隔离级别、索引、日志）都从这发散
- 为什么 PG 默认 RC 而 MySQL 默认 RR？ 设计取舍不同：PG 没有间隙锁，RC 更简单并发更好，强一致用 SSI；MySQL 的 RR 靠临键锁防幻读
- 什么时候选 PG？ 复杂查询、数据完整性、GIS/JSON/向量多能力需求。一个 PG 顶 MySQL 加 ES 加向量库的部分工作
- 什么时候选 MySQL？ 团队生态成熟、运维简单、读多写少标准业务
- RAG 场景怎么选？ 千万级以内用 pgvector（同库事务原生），更大规模或极低延迟用专用向量库