前言
很长一段时间里，项目数据库选型几乎都是 MySQL。
原因很简单：上手快、资料多、运维成熟，基本不会踩大坑。
但随着业务逐渐复杂，越来越频繁地遇到一个问题：
不是 MySQL 不好，而是它开始“不够用了”。
最终，在一个核心系统中，选择了从 MySQL 迁移到 PostgreSQL。
这篇文章不谈“谁更牛”，只聊 迁移的原因，以及迁移之后带来的真实变化。
一、最初选择 MySQL：完全没问题
在业务初期，系统非常典型：
- 表结构简单
- CRUD 为主
- 查询条件固定
- 并发量不算高
这种情况下，MySQL 的优势非常明显：
- 开发效率高
- ORM 支持好
- 运维成本低
- 社区资料极其丰富
? 在早期阶段，MySQL 是非常正确的选择。
二、问题开始出现：SQL 越来越“别扭”
随着业务发展，开始频繁遇到下面这些需求：
- 查询条件不断变化
- 一个接口要拼十几种筛选条件
- 统计 + 排序 + 分组 + 子查询
- 一条 SQL 变得又长又难维护
在 MySQL 中，经常出现：
- SQL 写得很“绕”
- 需要多次查询再在代码里拼结果
- 某些统计逻辑不得不下沉到应用层
数据库越来越像“存储工具”，而不是“计算工具”。
三、第一个痛点：复杂查询能力不足
举个很真实的例子：
用户行为统计 + 排名
在 PostgreSQL 中，一条 SQL 就能解决：
SELECT user_id, COUNT(*) AS cnt, RANK() OVER (ORDER BY COUNT(*) DESC) AS rankFROM user_logsGROUP BY user_id;
而在 MySQL 中（尤其是 8.0 之前）：
- 要么拆成多条 SQL
- 要么在业务代码中排序、计算排名
? PostgreSQL 把复杂逻辑留在数据库层，代码明显更干净。
四、JSON 数据：压倒性的迁移理由
后来系统里出现了大量 半结构化数据：
- 用户配置
- 动态属性
- 扩展字段
一开始在 MySQL 中用 JSON 字段，但很快发现问题：
- 索引能力有限
- 查询性能不稳定
- 复杂 JSON 查询写起来很痛苦
而 PostgreSQL 的 JSONB：
- 原生支持索引（GIN）
- 查询语法清晰
- 可以直接对 JSON 字段做过滤、排序
SELECT *FROM usersWHERE profile->>'city' = 'Beijing';
? 这一步之后，基本确定要迁移了。
五、事务与一致性：心理负担明显变小
在订单、资金相关逻辑中，越来越在意两点：
- 并发一致性
- 事务隔离级别是否“真有效”
PostgreSQL 的特点是：
- 真正的 MVCC
- 读写互不阻塞
SERIALIZABLE可用性高
迁移之后：
- 对“幻读”“并发写覆盖”的担心明显减少
- 很多地方不用再手写锁逻辑
? 数据库在帮忙兜底，而不是替数据库兜底。
六、索引与优化：PostgreSQL 更灵活
PostgreSQL 支持的索引类型非常丰富：
- 表达式索引
- 部分索引
- GIN / GiST / BRIN
例如直接对 JSON 字段建索引：
CREATE INDEX idx_cityON users ((profile->>'city'));
在 MySQL 中，这类需求往往只能靠冗余字段解决。
? PostgreSQL 给人的感觉是：
“你怎么查，我就怎么帮你优化。”
七、迁移后的真实感受
迁移完成后，并没有出现最担心的问题：
❌ 性能明显下降
❌ 运维复杂到失控
反而出现了这些变化：
- SQL 数量变少
- 业务代码更简单
- 报表类功能开发速度明显提升
- 很多逻辑不再需要写在代码里
当然，PostgreSQL 也有代价：
- 学习成本更高
- DBA 思维要求更强
- 不适合“无脑 ORM”
八、对 MySQL 和 PostgreSQL 的最终看法
MySQL 没有错，它只是更适合“简单明确的业务”。
而 PostgreSQL 更适合：
- 业务复杂
- 查询多变
- 强一致性要求
- 希望数据库承担更多计算能力的系统
结论是：
当你开始频繁吐槽 SQL 写得太难看、逻辑不得不放到代码里时，
PostgreSQL 很可能就是下一步。
九、写在最后
数据库选型，本质不是技术信仰，而是 业务匹配度。
并不后悔用 MySQL 起步，
但也庆幸在合适的时间，选择了 PostgreSQL。
