一文详解为什么我从MySQL迁移到PostgreSQL

 更新时间:2026年06月09日 10:09:27   作者:陌北v1  
从MySQL迁移到PostgreSQL是一个复杂但必要的过程,它能够为系统带来更高的性能、丰富的功能集和更强的扩展能力,这篇文章主要介绍了为什么我从MySQL迁移到PostgreSQL的相关资料,需要的朋友可以参考下

前言

在很长一段时间里,我的项目数据库选型几乎都是 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 rank
FROM user_logs
GROUP BY user_id;

而在 MySQL 中(尤其是 8.0 之前):

  • 要么拆成多条 SQL
  • 要么在业务代码中排序、计算排名

👉 PostgreSQL 把复杂逻辑留在数据库层,代码明显更干净。

四、JSON 数据:压倒性的迁移理由

后来系统里出现了大量 半结构化数据

  • 用户配置
  • 动态属性
  • 扩展字段

一开始在 MySQL 中用 JSON 字段,但很快发现问题:

  • 索引能力有限
  • 查询性能不稳定
  • 复杂 JSON 查询写起来很痛苦

而 PostgreSQL 的 JSONB

  • 原生支持索引(GIN)
  • 查询语法清晰
  • 可以直接对 JSON 字段做过滤、排序
SELECT *
FROM users
WHERE profile->>'city' = 'Beijing';

👉 这一步之后,我基本确定要迁移了。

五、事务与一致性:心理负担明显变小

在订单、资金相关逻辑中,我越来越在意两点:

  • 并发一致性
  • 事务隔离级别是否“真有效”

PostgreSQL 的特点是:

  • 真正的 MVCC
  • 读写互不阻塞
  • SERIALIZABLE 可用性高

迁移之后:

  • 对“幻读”“并发写覆盖”的担心明显减少
  • 很多地方不用再手写锁逻辑

👉 数据库在帮我兜底,而不是我替数据库兜底。

六、索引与优化:PostgreSQL 更灵活

PostgreSQL 支持的索引类型非常丰富:

  • 表达式索引
  • 部分索引
  • GIN / GiST / BRIN

例如直接对 JSON 字段建索引:

CREATE INDEX idx_city
ON users ((profile->>'city'));

在 MySQL 中,这类需求往往只能靠冗余字段解决。

👉 PostgreSQL 给我的感觉是:
“你怎么查,我就怎么帮你优化。”

七、迁移后的真实感受

迁移完成后,并没有出现我最担心的问题:

❌ 性能明显下降
❌ 运维复杂到失控

反而出现了这些变化:

  • SQL 数量变少
  • 业务代码更简单
  • 报表类功能开发速度明显提升
  • 很多逻辑不再需要写在代码里

当然,PostgreSQL 也有代价:

  • 学习成本更高
  • DBA 思维要求更强
  • 不适合“无脑 ORM”

八、我对 MySQL 和 PostgreSQL 的最终看法

MySQL 没有错,它只是更适合“简单明确的业务”。

而 PostgreSQL 更适合:

  • 业务复杂
  • 查询多变
  • 强一致性要求
  • 希望数据库承担更多计算能力的系统

我的结论是:

当你开始频繁吐槽 SQL 写得太难看、逻辑不得不放到代码里时,
PostgreSQL 很可能就是下一步。

九、写在最后

数据库选型,本质不是技术信仰,而是 业务匹配度

我并不后悔用 MySQL 起步,

但也庆幸在合适的时间,选择了 PostgreSQL。

到此这篇关于为什么我从MySQL迁移到PostgreSQL的文章就介绍到这了,更多相关MySQL迁移到PostgreSQL内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家!

相关文章

  • mysql中insert与select的嵌套使用解决组合字段插入问题

    mysql中insert与select的嵌套使用解决组合字段插入问题

    本节主要介绍了mysql中insert与select的嵌套使用解决组合字段插入问题,需要的朋友可以参考下
    2014-07-07
  • Win10下mysql 8.0.15 安装配置图文教程

    Win10下mysql 8.0.15 安装配置图文教程

    这篇文章主要为大家详细介绍了Win10下mysql 8.0.15 安装配置图文教程,具有一定的参考价值,感兴趣的小伙伴们可以参考一下
    2019-03-03
  • MySQL中explain语句的基本使用教程

    MySQL中explain语句的基本使用教程

    这篇文章主要给大家介绍了关于MySQL中explain语句的基本使用教程,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧
    2021-03-03
  • 一篇文章读懂什么是MySQL索引下推(ICP)

    一篇文章读懂什么是MySQL索引下推(ICP)

    当MySQL使用一个索引来检索表中的行时,可以使用ICP作为一种优化方案,下面这篇文章主要给大家介绍了如何通过一篇文章读懂什么是MySQL索引下推(ICP)的相关资料,文中通过示例代码介绍的非常详细,需要的朋友可以参考下
    2021-09-09
  • MySQL 数据丢失排查案例

    MySQL 数据丢失排查案例

    这篇文章主要分享了MySQL 数据丢失排查的一个案例,帮助大家更好的理解和学习使用MySQL数据库,感兴趣的朋友可以了解下
    2021-05-05
  • MySQL安装与配置:如何重置MySQL登录密码(windows环境)

    MySQL安装与配置:如何重置MySQL登录密码(windows环境)

    这篇文章主要介绍了MySQL安装与配置:如何重置MySQL登录密码(windows环境),具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教
    2023-12-12
  • 解决mysql的赋权操作之GRANT ALL PRIVILEGES ON *.* TO ‘root‘@‘%‘ IDENTIFIED BY ‘123456‘ WITH GRANT OPTION问题

    解决mysql的赋权操作之GRANT ALL PRIVILEGES ON *.*

    这篇文章主要介绍了解决mysql的赋权操作之GRANT ALL PRIVILEGES ON *.* TO ‘root‘@‘%‘ IDENTIFIED BY ‘123456‘ WITH GRANT OPTION问题,本文给大家分享两种情况分析分享解决方案,感兴趣的朋友一起看看吧
    2022-11-11
  • 从底层简析Python程序的执行过程

    从底层简析Python程序的执行过程

    这篇文章主要介绍了从底层简析Python程序的执行过程,包括注入操作码和封装程序等解释器执行层面的知识,需要的朋友可以参考下
    2015-06-06
  • mysql installer community 8.0.12.0安装图文教程

    mysql installer community 8.0.12.0安装图文教程

    这篇文章主要为大家详细介绍了mysql installer community 8.0.12.0安装图文教程,具有一定的参考价值,感兴趣的小伙伴们可以参考一下
    2018-08-08
  • MySQL优化必须调整的10项配置

    MySQL优化必须调整的10项配置

    这篇文章主要介绍了MySQL优化必须调整的10项配置,使用这些方法可以让你快速地获得一个稳健的MySQL配置,需要的朋友可以参考下
    2014-02-02

最新评论