做数据库选型这些年，被问得最多的一个问题就是：“高性能场景到底用 PostgreSQL 还是 MySQL？”以前我一般会打太极，说“看情况”，但做过的项目越多，我的回答越偏向一个方向：如果是真正的高性能、高并发、复杂查询混合的场景，我推荐 PostgreSQL。这不是说 MySQL 不行，而是大家在聊“高性能”的时候，很多时候其实是在聊“复杂查询效率”和“并发一致性”，而这两个点上，PostgreSQL 的底子确实更厚。这篇文章我就从实际落地的角度，把 PostgreSQL 在哪些地方比 MySQL 强、强在哪里、什么时候别乱选，以及配置和排坑的实操心得，一次说清楚。
内容面向数据库开发者、后端工程师、架构师，也适合正在纠结选型的团队。如果你只是想装个数据库跑几个简单接口，MySQL 足够；但如果你想支撑报表分析、地理数据、复杂 JSON 处理、大批量并发写入，同时又不想被 SQL 限制住，那 PostgreSQL 值得你认真看下去。
1. 从真实场景看：为什么“高性能”会绕开 MySQL
1.1 一个让人印象深刻的查询例子
先从一个让我彻底“倒戈”的案例说起。之前做一个订单分析系统，核心表大概 8000 万行，日均新增 200 万行。业务方给的需求是：按用户、时间段、商品类目三个维度统计销售额，并返回每个维度的 Top 10。MySQL 8.0 下用一坨子查询 + 窗口函数跑了 40 多秒，后来优化成临时表 + 多个索引，降到 20 秒，但还是慢。把同样一套 SQL 逻辑迁到 PostgreSQL，没改太多，只调整了窗口函数的写法，跑出来的结果不到 3 秒。这个差距不是偶然，它来自两套数据库对复杂查询处理方式的本质区别。
很多人误以为“高性能”就是“单条简单查询快”，实际上复杂报表查询才是压垮 MySQL 的主要场景。MySQL 的优化器在单表简单查询上确实不差，索引点查、主键查询都很快，可一旦涉及多表 JOIN、子查询、窗口函数、CTE 这些复杂结构，MySQL 的执行计划就经常“犯迷糊”。PostgreSQL 的优化器则会尝试多种连接顺序、多种扫描策略，生成更合理的计划。
另外，PostgreSQL 对复杂查询的支持几乎是全功能的：递归 CTE、窗口函数、LATERAL JOIN、聚合过滤等等，这些在 MySQL 里要么不支持，要么支持得“半吊子”。业务越复杂，SQL 表达越高级，PostgreSQL 的优势就越明显。
1.2 高性能不等于“跑得快”，关键在复杂查询和并发控制
再深入一点。数据库的高性能可以拆成两个维度：单查询延迟和整体吞吐。单查询延迟靠优化器、索引、存储引擎；整体吞吐靠并发控制、连接管理、写入机制。
MySQL 默认使用 InnoDB，锁粒度是行锁 + 间隙锁，写并发下需要处理锁竞争。PostgreSQL 使用多版本并发控制，同样也是行级锁定，但实现上更“激进”：读不会阻塞写，写不会阻塞读。这在报表系统、OLTP 混合场景下体验差异非常明显。MySQL 在默认隔离级别（可重复读）下，一个事务在跑聚合查询时，另一个事务要更新相关行，通常会被阻塞等待。PostgreSQL 因为有更完善的 MVCC 机制，快照隔离做得更彻底，读操作根本不需要加锁，也不会拿到中间态的数据。
所以那些“既要支撑高并发写入，又要随时跑分析查询”的系统，PostgreSQL 的混合负载能力要稳得多。MySQL 当然也能做读写分离，把分析和线上业务拆开，但这是架构层面的妥协；而 PostgreSQL 本身就能扛住一定程度的混合负载。
2. PostgreSQL 的核心优势拆解：不是“另一个数据库”那么简单
2.1 查询优化器与执行引擎：同样一条 SQL，计划差很多
PostgreSQL 的优化器是基于代价的，它会收集表的统计信息，估算每种执行方式的成本，然后选一条成本最低的。这套机制的关键在于它考虑了多种连接顺序。比如三张表 JOIN，MySQL 很多时候按 SQL 写的顺序去连接，PostgreSQL 则会尝试 A-B-C、A-C-B、B-A-C 等所有排列，选出最优的。
实际操作时，我在 PostgreSQL 里经常用EXPLAIN ANALYZE查看执行计划和实际执行时间。你会发现它对索引选择非常敏感，对数据分布的估算也更准确。比如一个字段有 30% 的数据是同一个值，MySQL 经常放弃索引，做全表扫描，而 PostgreSQL 会根据统计信息判断“即使 30% 选择性，还是可以用位图扫描”来减少回表次数。
另外，PostgreSQL 支持并行查询。默认配置下，max_parallel_workers_per_gather是 2，在多核服务器上可以把单条复杂查询拆成多个并行任务，显著降低延迟。MySQL 8.0 虽然也引入了并行查询，但范围和成熟度都比 PostgreSQL 差一截。
2.2 并发控制：MVCC 实现细节带来的隐性差异
MySQL 和 PostgreSQL 都宣称支持 MVCC，但实现方式不同，导致行为差异。
MySQL InnoDB 的 MVCC 是“回滚段 + 撤销日志”实现，旧版本数据会保留在 undo 日志里，读操作需要顺着版本链找到可见版本。PostgreSQL 则是把旧版本行直接留在表页中，通过xmin/xmax系统字段判断可见性。这种差异带来两个关键影响：
第一，PostgreSQL 的读操作极少被阻塞。即使有长事务在跑，普通的SELECT也不会堵在后面。MySQL 在某些隔离级别下，可能出现lock wait timeout，尤其是在混合读写压力较大时。
第二，PostgreSQL 的旧版本数据需要 vacuum 清理，如果 vacuum 跑得不好，表会膨胀，占用磁盘空间，查询变慢。MySQL 的 undo log 会自动回收，不需要专门维护。这就意味着 PostgreSQL 需要运维上更关注 vacuum 的配置和监控。
从性能角度说，PostgreSQL 的 MVCC 让写事务的开销更可控。更新一行时，它只需要插入一个新版本，不需要维护复杂的 undo 链。而 MySQL 更新一行时，写 undo、更新聚簇索引、更新二级索引，步骤更多。在高频更新场景下，PostgreSQL 的吞吐表现往往更加稳定。
2.3 数据类型与扩展能力：从 JSON 到时空数据
PostgreSQL 的数据类型丰富度在开源数据库里是独一档的。原生支持数组、JSON/JSONB、范围类型、枚举、网络地址、几何类型，还通过 PostGIS 扩展支持完整的地理空间数据。如果你要做一个 LBS 应用，PostgreSQL + PostGIS 可以直接在 SQL 里算距离、做空间索引、判断点面关系，MySQL 则要借助外部计算或自己实现。
JSONB 是另一个典型优势。MySQL 8.0 的 JSON 类型是二进制存储，但索引支持有限，很多场景只能靠函数索引模拟。PostgreSQL 的 JSONB 支持 GIN 索引，可以高效查询 JSON 内部的键值，还能在 SQL 里方便地使用->>、@>等操作符。我做过一个业务动态字段特别多的系统，用 JSONB 存扩展属性，通过 GIN 索引做条件过滤，查询性能和写扩展的灵活性都很好。
这些能力不是花架子，它们决定了你能不能在数据库层面完成更复杂的计算。高性能场景往往不只是“快”，还得“能算”。当业务逻辑可以在数据库里直接完成时，减少了应用层传输和计算，整体延迟自然下降。
3. 参数调优和配置注意事项：高性能不是开箱即用
3.1 PostgreSQL 关键配置项：shared_buffers、work_mem、effective_cache_size
很多人装了 PostgreSQL 直接用默认配置，然后发现性能一般。默认配置是为了保证在任何机器上都能跑起来，参数设置非常保守。想要高性能，必须根据硬件和业务调整。
首先看shared_buffers。这是 PostgreSQL 自己的共享缓冲池，建议设置为物理内存的 25%~40%。比如 64GB 内存的机器，设个 16GB~24GB 是合理的。太小会导致缓存命中率低，频繁读磁盘；太大又会影响系统底层的文件缓存效果。
然后是work_mem。这个参数决定单个排序、哈希连接等操作能使用的内存。默认只有 4MB，复杂查询一旦涉及大量排序，就会溢写到临时文件，性能断崖式下降。我一般先设为 32MB~64MB，然后观察有没有temp file出现，再逐步调整。注意：work_mem是每个操作都可能分配的内存量，如果并发连接数高，设太大容易导致 OOM，需要结合max_connections一起评估。
还有effective_cache_size。这个参数告诉优化器操作系统文件缓存有多大，不是实际分配内存，只是用来做成本估算。建议设置为总内存的 50%~75%。如果设置太小，优化器会低估文件缓存的作用，倾向于使用索引扫描而不是顺序扫描，有时反而选错执行计划。
一个我常用的初始配置（64GB 内存、16 核服务器）大概是这样：
shared_buffers = 16GB work_mem = 64MB maintenance_work_mem = 2GB effective_cache_size = 48GB max_connections = 200 max_parallel_workers_per_gather = 4这些参数不是万能的，但因为影响面大，优先调整它们通常能解决 80% 的“PostgreSQL 怎么还不如 MySQL 快”的问题。
3.2 索引策略：部分索引、表达式索引、GIN/BRIN
PostgreSQL 的索引类型丰富，这是它高性能的重要来源。除了常见的 B-tree，还有 GIN、GiST、BRIN、Hash 等索引，而 MySQL 主要就是 B-tree（8.0 开始支持函数索引，哈希索引有限）。
部分索引是我在实战中非常喜欢用的。它允许只对满足条件的数据建索引，比如：
CREATE INDEX idx_order_paid ON orders (paid_at) WHERE status = 'paid';这个索引只包含已支付订单，体积小，更新代价低，查询时如果条件里带了status = 'paid'，优化器会自动使用它。类似的效果在 MySQL 里只能用普通索引加冗余逻辑，做不到这么干净。
表达式索引也很有用。比如经常按下单月份查询：
CREATE INDEX idx_order_month ON orders (date_trunc('month', created_at));查询条件写成date_trunc('month', created_at) = '2025-06-01'时就能走索引。MySQL 8.0 虽然支持函数索引，但使用起来没有 PostgreSQL 自然。
还有 BRIN 索引，适合存储时序数据的大表。如果表数据按时间顺序插入，BRIN 索引可以做到极小体积、极低维护成本，查询大范围时间数据时速度惊人。比如日志表，几千万行，BRIN 索引只有几百 KB，而普通 B-tree 索引可能几百 MB。这个特性 MySQL 没有对应物。
3.3 与 MySQL 调优对比：不要用 MySQL 的思路配 PostgreSQL
有些从 MySQL 转过来的同学，会把 MySQL 的调优思路直接套到 PostgreSQL 上，结果踩坑。典型的例子是innodb_buffer_pool_size设得很大，于是shared_buffers也设到 80% 内存，导致系统几乎没有可用于文件缓存的内存，整体性能反而下降。PostgreSQL 希望shared_buffers和操作系统文件缓存共同工作，而不是独吞所有内存。
另一个例子是连接数。MySQL 的线程模型通常每个连接一个线程，连接多了上下文切换开销很大，所以很多架构里会限制连接数，并引入连接池。PostgreSQL 是进程模型，每个连接对应一个操作系统进程，连接本身也比较重，所以同样需要连接池。但如果你把max_connections调到 2000，却发现物理内存不够，因为每个进程至少消耗数 MB 内存。所以我的经验是：连接数不要一味调大，应用层用 PgBouncer 或连接池中介，数据库层保持 200~300 的连接上限，性能更稳定。
而且 PostgreSQL 的max_connections提高后，还可能影响锁管理、共享内存分配，不是简单改个数字就行。
4. 什么时候该选 PostgreSQL，什么时候继续用 MySQL
4.1 明确适合 PostgreSQL 的场景
有几类场景是我会毫不犹豫推荐 PostgreSQL 的。
第一，复杂查询密集型业务。比如 BI 报表、数据看板、运营后台，SQL 全是多表 JOIN、子查询、窗口函数。PostgreSQL 的优化器和执行能力会省掉你一大半的 SQL 改写心思。
第二，地理位置相关应用。PostGIS 几乎是最好的开源地理信息计算方案，没有之一。GPS 轨迹查询、商圈匹配、附近的人这类需求，用 MySQL 实现非常痛苦，PostgreSQL 只需要空间索引和少数几个函数。
第三，JSON 文档和关系数据混存。PostgreSQL 能同时处理结构化关系和半结构化的 JSONB，一个系统里两种数据模型可以无缝 JOIN。这在业务字段经常变化、需要快速迭代的场景里太有用了。
第四，写多读多且不能阻塞的系统。因为 PostgreSQL 的读不阻塞写、写不阻塞读，所以很多在线交易类系统也能在单实例上支撑不错的混合负载。
4.2 明确适合 MySQL 的场景
虽然我推荐 PostgreSQL，但 MySQL 也不是一无是处，以下场景继续用 MySQL 完全合理。
首先是极其简单的读写场景。比如纯 CRUD 系统，单条点查、按主键访问，MySQL 的 InnoDB 优化得非常好，稳定且资料多，招人容易。
其次是生态依赖。很多老系统、云厂商托管服务、开源平台默认支持 MySQL，比如 WordPress、一些商业系统。这时强行迁移到 PostgreSQL，收益可能不大，成本却很高。
第三是极端高并发写入但数据模型极简的场景，比如秒杀、计数器。MySQL 的稳定性验证范围更广，很多人也更熟悉它的主从复制、分库分表方案。PostgreSQL 也能做，但 MySQL 生态里关于分库分表中间件的成熟度更高。
还有一点，如果团队完全没人熟悉 PostgreSQL，运维能力和工具链也偏 MySQL，那就别为了“酷”强行换。选型不只是技术对比，更是团队能力匹配。
4.3 从 MySQL 迁移到 PostgreSQL 的实操建议
如果决定迁，别直接用工具倒数据就完事。SQL 语法差异、隐式类型转换、时间/字符处理逻辑都要梳理。MySQL 的双引号默认是字符串，PostgreSQL 里是标识符；MySQL 的GROUP BY更宽松，PostgreSQL 要求非聚合列必须出现在 GROUP BY 中；LIMIT和OFFSET的语义虽然一样，但性能表现不同。
我建议先做 SQL 兼容性评估，找出所有涉及GROUP BY、子查询、函数命名的 SQL。比如 MySQL 的DATE_FORMAT、IF()，PostgreSQL 要改成TO_CHAR、CASE WHEN。数据迁移工具可以选pgloader，它支持从 MySQL 直接迁移到 PostgreSQL，自动处理大部分类型转换，但索引、约束建议迁移后手工重建。
测试阶段要重点看慢查询，因为优化器不同，原来走索引的 SQL 可能走全表扫描。我一个项目里迁移后有大约 10% 的 SQL 执行计划变了，需要重建索引或者重写 SQL。
5. 常见问题与实操排查实录
5.1 连接数打满：进程模型先别慌
PostgreSQL 默认max_connections是 100，这在稍微有点并发的系统里很容易打满。现象就是应用报“FATAL: sorry, too many clients already”。MySQL 默认 151，大家很少遇到，因为中间件、连接池都会撑住。
处理方式不是直接调大max_connections，而是优先加连接池。应用层可以接 HikariCP、Druid 等连接池，数据库前面也可以放 PgBouncer。PgBouncer 是轻量级数据库连接池，能把前台连接复用到一个很小的连接集上，降低进程开销。我有一套组合拳：应用连接池设置 50 个连接，叠加 PgBouncer 把数据库连接压到 20 个以内，这样max_connections保持 100 也够用。
如果你实在想调大，记得同时评估shared_buffers和内核参数。每个 PostgreSQL 进程在默认配置下大概占用 5-10MB 内存，2000 个连接意味着 10-20GB 开销，这个账要算清楚。
5.2 主从复制与高可用：PG 的主从和 MySQL 差异很大
MySQL 的主从复制基于 binlog，异步或半同步。PostgreSQL 基于 WAL 日志归档和流复制，默认是异步，也可以配置同步复制。两者都能做主从切换，但 PostgreSQL 的复制在数据一致性上更严格，没有 MySQL 那种因为事务执行顺序导致的隐性问题。
实际操作中，PostgreSQL 做主从需要先配置wal_level = replica，然后做基础备份，再配primary_conninfo。这里涉及pg_basebackup工具，比 MySQL 的配置过程多一些步骤，但逻辑清晰。切换时可以用pg_ctl promote或者依赖 repmgr、Patroni 等工具。
另外提醒一个常见坑：PostgreSQL 从库不支持写操作，读请求可以被从库分流，但复制是物理级的，不像某些 MySQL 方案可以基于规则过滤。如果需要按库或按表同步，PostgreSQL 有逻辑复制，可以指定发布订阅的表，这个能力 MySQL 的逻辑复制也有，但 Postgres 的表结构变更处理要小心。
5.3 性能骤降排查：vacuum、索引失效、统计信息滞后
使用 PostgreSQL 一段时间后，如果你发现某个查询突然变慢，先别急着加硬件。大概率是统计信息过期或表膨胀。
统计信息过期会导致优化器估算行数错误，选错执行计划。解决方式是跑ANALYZE table;，或者设置自动 analyze 的阈值。PostgreSQL 默认的autovacuum会做这件事，但有时候因为长事务，autovacuum 跟不上，你需要手动处理。
表膨胀是 PostgreSQL 特有的问题。大量更新删除后，旧版本行留在表里，导致扫描成本上升。膨胀严重时，VACUUM FULL可以彻底回收空间，但它会锁表。所以生产环境要提前规划维护窗口，或者用pg_repack在线重建表。
基于我多次救火的总结，建议日常监控三件事：pg_stat_activity看有没有长期挂起的事务，pg_stat_user_tables看n_live_tup和n_dead_tup的比例，pg_stat_statements看慢查询分布。把这些数据接进监控系统，比临时拍脑袋调参有用得多。
5.4 安装和版本选择：别再纠结“最新版”
很多新手问 PostgreSQL 下载哪个版本，官方下载页上版本很多。我的建议是不要追最新大版本，选当前稳定分支的最近小版本。比如 PostgreSQL 17 已经发布，但如果你在生产环境，建议选 16 或 15 系列的最新补丁版本，生态兼容性更好。在 Windows 和 Linux 上的安装方式不同，Windows 用安装包，Linux 用发行版仓库或官方源。安装后第一件事是配置pg_hba.conf和postgresql.conf，很多服务启动失败都和权限配置有关。
MySQL 同样，下载官网的 MySQL Community Server 并注意选择 8.0 LTS 版本，而不是预计会很快迭代的开发版本。现在的安装教程虽然多，但很多人卡在初始化、服务启动、root 密码上。实际上这两个数据库安装都不复杂，复杂的是安装完之后的参数配置和安全加固。数据库是高危环节，不要拿生产环境练手。
我的实际体会
做了这么多年数据库选型，我不否认 MySQL 在简单场景里的易用性，但 PostgreSQL 从一开始就是朝着“学院派”的方向设计，它把数据一致性、SQL 标准完整度、扩展能力放在首位，然后在性能上不断打磨。正因如此，在高性能、复杂业务混合的场景里，它确实比 MySQL 更省心。如果你的系统还处于早期，能自由选型，我强烈建议你认真评估 PostgreSQL。如果已经在 MySQL 上运行稳定，也别盲目迁移，先拿复杂查询和数据一致性要求高的模块做试点，用数据说话。数据库没有绝对的好坏，只有合不合适，但 Postgres 在很多关键点上，选择它你会省下不少未来的麻烦。
