从 MySQL 换到 PostgreSQL，一年后我来说说值不值

去年这时候，我把手头一个项目的数据库从 MySQL 迁到了 PostgreSQL。当时就有人劝我：别折腾，MySQL 用得好好的，换库图啥？一年过去，我可以负责任地说，这趟折腾值了，但过程没想象中那么轻松。

为什么想换？

起因挺简单。项目里有一张表，存的是用户的行为日志，一天涨几百万行。MySQL 这边我又是分区又是优化索引，查询还是越来越慢。尤其是那种带 JSON 字段的模糊搜索，写起来又丑又难调。后来朋友提了一嘴：你这需求，PostgreSQL 的 JSONB 和全文检索天生就合适。

我就去试了。不试不知道，JSONB 对 JSON 字段的支持是真舒服，直接建 GIN 索引，查询速度肉眼可见地快。全文检索更不用说了，中文分词配好之后，搜索体验直接上一个档次。

迁移过程中踩的坑

先说数据类型。MySQL 的 TINYINT(1) 到了 PG 里没有对应物，布尔值得自己理一遍。自增主键从 AUTO_INCREMENT 变成 SERIAL 或者 IDENTITY，写 SQL 的习惯要改。最坑的是时间字段，datetime 和 timestamp 的语义不一样，老代码里凡是跟时间比较的地方，我都得重新过一遍。

工具链也得换。Navicat 用惯了，PG 生态里我更推荐 DBeaver，开源免费，功能还全。命令行 psql 比 mysql 命令好用，\d 表名 直接看表结构，比 DESC 强多了。

一年用下来的真实感受

性能这块，同配置下复杂查询 PG 确实更能打，特别是窗口函数和 CTE，写报表逻辑省了太多事。数据完整性上，PG 的约束和外键检查更严格，反过来逼着你把数据模型设计好。

但也有不习惯的地方。PG 的内存配置参数比 MySQL 多，刚上手容易懵，我调 shared_buffers 就调了好几天。还有运维生态，MySQL 的现成工具和文档明显更多，出问题好查。PG 社区也很活跃，就是中文资料相对少一点。

对了，最近国产大模型下载量破百亿这事大家应该都看到了，AI 应用一多，数据库选型又成了热门话题。我的建议是：别跟风，先看业务。读写简单、团队熟 MySQL，就继续用；复杂查询多、JSON 用得多、要全文检索，PG 值得一试。

总结

值不值？我觉得值。但前提是你有时间和精力去折腾。迁移不是复制粘贴，是把业务逻辑重新理解一遍的过程。如果你也在犹豫，找个非核心项目先试水，跑一两个月再做决定。