做数据库选型这些年被问得最多的一个问题就是“高性能场景到底用 PostgreSQL 还是 MySQL”以前我一般会打太极说“看情况”但做过的项目越多我的回答越偏向一个方向如果是真正的高性能、高并发、复杂查询混合的场景我推荐 PostgreSQL。这不是说 MySQL 不行而是大家在聊“高性能”的时候很多时候其实是在聊“复杂查询效率”和“并发一致性”而这两个点上PostgreSQL 的底子确实更厚。这篇文章我就从实际落地的角度把 PostgreSQL 在哪些地方比 MySQL 强、强在哪里、什么时候别乱选以及配置和排坑的实操心得一次说清楚。内容面向数据库开发者、后端工程师、架构师也适合正在纠结选型的团队。如果你只是想装个数据库跑几个简单接口MySQL 足够但如果你想支撑报表分析、地理数据、复杂 JSON 处理、大批量并发写入同时又不想被 SQL 限制住那 PostgreSQL 值得你认真看下去。1. 从真实场景看为什么“高性能”会绕开 MySQL1.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 的优化器是基于代价的它会收集表的统计信息估算每种执行方式的成本然后选一条成本最低的。这套机制的关键在于它考虑了多种连接顺序。比如三张表 JOINMySQL 很多时候按 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/BRINPostgreSQL 的索引类型丰富这是它高性能的重要来源。除了常见的 B-tree还有 GIN、GiST、BRIN、Hash 等索引而 MySQL 主要就是 B-tree8.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什么时候继续用 MySQL4.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 在很多关键点上选择它你会省下不少未来的麻烦。