选型：PostgreSQL vs MySQL

这一课你将能做到

1. 按场景列出 PG 与 MySQL 各自更常胜出的理由（至少各三条）
2. 用工程语言解释 CodeRoadMap 坚持 MySQL 8 的原因，而不是「谁更高级」
3. 对「新项目要不要上 PG」给出可辩护的建议框架（含双库策略警戒线）

为什么要学

面试与架构评审常问：「为什么选 PostgreSQL / MySQL？」答「网上说 PG 更强」站不住脚。选型是 场景、团队、生态、迁移成本 的函数。

本站结论先亮牌：生产权威数据源继续是 MySQL 8；本 track 培养你看懂另一条主流路线，并在全栈路线图节点上能对话。官方两边文档都要会查，而不是站队。

先建立图像

         需求特征
            │
    ┌───────┼───────┐
    ▼       ▼       ▼
  通用 OLTP  JSONB/GIS  已有 MySQL 资产
  国内 RDS   复杂分析    教程/迁移沉淀
    │         │           │
    ▼         ▼           ▼
  常选 MySQL  常选 PG    坚持 MySQL

场景	更常见选择	简要理由
通用 OLTP、国内运维人力	MySQL	DBA 经验、云 RDS 成熟
JSONB 重度过滤、复杂 SQL	PostgreSQL	运算符 + GIN + 标准 SQL 能力
地理数据	PostgreSQL + PostGIS	事实标准
只读副本扩展	两者皆可	生态与团队熟悉度决定
Serverless 分支库	PG 产品线多（如 Neon）	产品形态贴近 PG
本站课程/进度业务	MySQL	已投入 schema 与教程主线

跟着做

步骤 1：重读本站约束

打开 backend 数据源配置与 schema.sql，确认：

• JDBC 指向 MySQL
• 表以关系列为主，JSON 扩展需求有限

写一句：「若今天强行切 PG，会炸在哪些文件？」（迁移、类型、文档、跟练环境）

步骤 2：填一张「我们队」矩阵

复制下表到笔记，按你假想的团队打勾：

问题	偏 MySQL	偏 PG
谁会做备份与故障切换？
是否强依赖 JSONB 查询？
是否要上 PostGIS？
现有代码/SQL 方言？
云厂商哪个更熟？

没有「标准答案」，有的是权重。

步骤 3：论证一个具体需求

题目：课时需要「全文检索 + 标签过滤」。

• MySQL 方案：全文索引 / 外部搜索（Elasticsearch）+ 关系标签表
• PG 方案：tsvector 或扩展 + JSONB/数组标签 + GIN

各写三行利弊。结论允许是「继续 MySQL + ES」，只要理由完整。再补一句：「搜索若独立成服务，主库引擎选型权重会下降」——避免把所有能力都塞进单一 RDBMS。

步骤 4：画双库警戒线

允许：OLTP MySQL ←ETL/CDC→ 分析 PG
禁止：同一用户进度双写两库却无事务方案

双写极易不一致。能单库解决不要拆。若必须同步：明确谁是真相源、延迟是否可接受、冲突如何解。

步骤 5：路线图打点

在 全栈路线图 标出 MySQL 与 PostgreSQL 节点。用一句话告诉新人：「学 PG track ≠ 改本站生产库。」对照 SQL 路线图 看节点是否重复覆盖，避免以为「勾了 PG 就等于 MySQL 主路径可跳过」。

步骤 6：写一段对外说明（100 字内）

面向同学或同事：为什么本站教 MySQL 主路径，同时提供 PG essentials。避免贬低任一产品。写完后用三问自检：有没有场景？有没有成本？有没有回滚？缺一项就再改一版。

步骤 7：做一次「假想 ADR」提纲

用四行记下架构决策记录雏形：

1. 背景（要存什么、查什么）
2. 候选（MySQL / PG / 其它）
3. 决定与理由（三条以内）
4. 后果（迁移、监控、人员）

不必写成正式文档；养成「可评审」的表达习惯即可。

讲清楚要点

1. 没有永远更好的数据库，只有匹配度：功能清单赢不了运维与迁移成本。
2. 本站选 MySQL 的工程原因：教程主线一致、本机 MySQL80 跟练、业务以关系表为主、已有 schema.sql/V*.sql 投资。
3. PG 值得学的原因：JSONB、扩展、标准 SQL、云原生 PG 服务、面试常见。
4. 因为 切换引擎成本主要在方言与工具链，所以 用 profile 实验而不是冲动切生产。
5. 团队技能是硬约束：没人会 vacuum / 复制，功能再炫也危险。
6. 评估要写下来：场景、备选、风险、回滚；口头站队不算架构。
7. 默认隔离与工具链也算成本：PG 默认 Read Committed、MySQL InnoDB 常默认 RR；监控指标、备份命令、连接串都不同，选型要把「第二天谁值班」算进去。

你可能会懵的地方

• 「PG 更遵守标准」是否等于该换？
  标准友好是加分项，不是迁移令箭。看查询需求与团队。

• Oracle/SQL Server 呢？
  企业常见；本站主路径不展开。选型框架同样适用。

• MongoDB 会不会取代？
  文档库解决另一类问题；本站进度与课程仍适合关系约束。见其它 track。

• 性能谁更快？
  取决于负载与调优。基准测试要自己的模型，莫背评测截图。

• 学完是否要在简历写「精通 PG」？
  写「熟悉基础 DDL/JSONB/事务/Spring 接入」更诚实；精通需要生产经验。

• 新创项目「两边都不熟」怎么办？
  优先选团队已有托管与告警经验的那一个；用本 track 补另一边的阅读能力，而不是同时上两套生产库。

错法对照

错法	问题	正解
「PG 全面优于 MySQL」	选型失真	按场景矩阵
「本站用 MySQL 所以 PG 过时」	视野窄	PG 是主流之一
无迁移计划就改生产 URL	事故	实验库 + 正式迁云方案
双写两库当「高可用」	一致性灾难	单一真相源 + 同步管道
只比星星标数	忽略运维	加上团队与云厂商因素

自测三问

1. 举出本站坚持 MySQL 的两个非「性能」理由。
2. 什么需求会让你在新项目中优先评估 PostgreSQL？
3. 为何「核心实体双写 MySQL+PG」通常是坏主意？

小结一句话

MySQL 服务本站主路径与跟练；PostgreSQL 是能力扩展与常见云栈选项——用场景矩阵选型，而不是口号。

官方延伸

• PostgreSQL 官方站
• MySQL 8.0 参考手册