我为什么从 MySQL 投奔 PostgreSQL（以及没有全盘迁移）

Sat, 27 Jun 2026 10:00:00 +0800

上一篇《MySQL 千疮百孔，为什么没人能替代它》发出去之后，收到的留言比我预想的多。大部分不是技术讨论，是一种很微妙的共鸣：我知道它有问题，但我确实不知道该不该换。

这其实才是真正的困惑。

你看完 MySQL 那堆坑——ENUM 排序按定义位置、级联外键不触发 trigger、DDL 隐式提交——你的第一反应不该是"PostgreSQL 好，我要换"。你的第一反应应该是：我当前的项目，这些坑到底有没有咬到我？

如果没咬到，别动。

如果咬到了，也不能说换就换。你得知道换了之后会面临什么全新的疼法。

这篇就是讲这个的。

让我的手指终于放在键盘上的那个瞬间

先说我的触发点。

不是什么宏大的"我们要用更先进的数据库"。是一个凌晨两点半的告警电话。

线上 MySQL 实例的活跃连接数冲破了 500。thread_cache_size 已经调过一轮了，max_connections 也放宽过。但 MySQL 的 thread-per-connection 模型到了这个量级，上下文切换已经压垮了 CPU。新连接进不来，已有查询跑不完，连接池开始拒绝请求。回滚也回不干净，因为 DML 都被堵在了锁等待队列里。

我试过调参数、重启连接池、杀掉慢查询。能做的都做了，只够撑到天亮。

天亮以后我查了接下来半年要上线的功能排期。三个和搜索有关的，两个需要地理查询，还有一个说想在用户标签里做 JSON 过滤。MySQL 的 JSON 你是知道的——每次解析全文，索引靠虚拟列绕路，这不是能用，是将就。

那天中午我开了个会。结论不是"PG 更好"，是"在这个点上，不改的成本已经超过改的成本了"。

但我仍然没有做全盘迁移。这篇就是告诉你我换了什么、没换什么、以及换完之后才知道的学费。

第一块：什么让我决定换

连接数瓶颈——不是 PG 更好，是 PgBouncer 把它变成了可控问题

MySQL 的 thread-per-connection 模型在 <100 连接时没什么感觉。到了 200+，你就开始频繁看 Too many connections。到 500+，运维基本靠祈祷。

这问题技术上不是 MySQL 不能处理高并发——淘宝、Facebook 都在用——但那是建立在应用层做了极其精细的连接管理之上的。大部分团队没有那个资源。

PostgreSQL 本身也是 fork-per-connection，每个连接 2-5 MB 基础内存，直接连 500 个也扛不住——甚至比 MySQL 更差。但 PG 加 PgBouncer 的组合把问题结构化了：你在应用层维持几百上千个连接，PgBouncer 用事务池把它们复用到 PG 端的几十个连接上。

迁移实战 on Zampo Blog

我为什么从 MySQL 投奔 PostgreSQL（以及没有全盘迁移）

让我的手指终于放在键盘上的那个瞬间

第一块：什么让我决定换

连接数瓶颈——不是 PG 更好，是 PgBouncer 把它变成了可控问题