上个月帮一个朋友排查线上数据库慢查询他的订单统计接口在MySQL里跑了整整6秒才出结果表也就几百万行索引该加的都加了EXPLAIN看执行计划也没发现全表扫描。后来把同一套SQL和数据量迁到PostgreSQL的测试实例配合并行查询和部分索引优化后单次查询稳定在400毫秒以内。这不是个例也不是我收了谁的好处费而是这两年做性能测试和数据库选型咨询时反复验证过的趋势在高性能场景尤其是复杂查询和混合负载下PostgreSQL比MySQL的胜面大得多。这篇内容不打算写成数据库教科书我想从一个实战DBA和架构师的角度把为什么推荐用PostgreSQL、MySQL什么时候仍然够用、以及换过去之后会踩到哪些坑这三件事讲透。适合正在做数据库选型的技术负责人、被线上慢查询折磨的开发同学以及想认真评估这两种数据库真实差距的运维同行。你不需要认同所有结论但看完之后至少能有一套自己的判断逻辑。1. 先把高性能拆清楚不同负载下两种数据库的胜负完全不同高性能这个词被用滥了。很多人一听说某某数据库性能好就直接决定换库结果换完发现还不如从前。问题出在哪里因为高性能本身不是一个维度它是至少五个维度的组合读写比、并发度、查询复杂度、数据一致性要求、扩展方式。在这五个维度上MySQL和PostgreSQL的偏向完全不同。1.1 高性能不是一个口号而是五种负载的加权求和我习惯把数据库的业务负载拆成几种典型画像选型时先对号入座短事务点查型大量基于主键或唯一索引的等值查询事务极短响应时间要求在毫秒级。典型如用户登录、会话校验、支付回调。高并发写入型写入量大通常配合消息队列削峰对写入吞吐敏感但对读取的复杂度要求不高。典型如日志采集、订单落库。复杂查询分析型几条SQL特别难写多表关联、多层子查询、窗口函数、分组聚合数据量大跑起来时间以秒甚至分钟计。典型如报表中心、运营看板、订单统计。半结构化数据混合型业务数据里既有强关系结构又要存储和检索JSON、数组、地理位置这类灵活格式。强一致与恢复要求型绝不能丢数据主从切换要稳崩溃恢复要快对同步延迟极其敏感。典型如账务流水、库存扣减。如果你的业务主要是第一种和第二种MySQL到今天仍然是很靠谱的选择这不是标题能否定的。但如果你明显处于第三、第四、第五种PostgreSQL几乎在每个维度上都更好。本文标题里说的高性能场景指的就是后面这三类的叠加而不是单纯把点查QPS堆高。1.2 从纯OLTP到纯OLAP之间的光谱两边各有地盘业内常说MySQL是标准OLTP数据库但其实它的定位更准确来说是短平快交易型数据库复杂分析能力是短板。PostgreSQL则处在功能型通用数据库的位置它既能扛住正常的交易负载又能处理相当程度的分析负载是OLTP与OLAP光谱中间区域的最优解之一。我问过一些选型团队的负责人他们在什么场景下会后悔当初选了MySQL答案高度集中在两类第一类是业务上线两年后报表需求爆发原先的只要读写快就行瞬间变成这条统计SQL怎么可以这么慢第二类是数据模型越来越灵活产品经理不断往一张表里塞JSON字段MySQL用JSON_TYPE、JSON_EXTRACT拼SQL拼到怀疑人生。反过来选了PostgreSQL后悔的也有但通常是因为团队完全没接触过PG把运维预算想得太简单或者业务确实简单到连一个复杂查询都不会出现。数据库选型没有纯粹的谁比谁强只有谁和你的业务画像更匹配。负载画像MySQL适用度PostgreSQL适用度说明主键点查、短事务极佳良好MySQL的InnoDB在纯点查上有长期优化PG绝对性能稍低但相差不大高并发批量写良好良好两者都需要合理分批PG需注意表膨胀与WAL调优多表复杂关联一般偏弱很好PG优化器与索引类型优势明显窗口函数/分析SQL较弱8.0后才支持很好PG早期版本就原生支持并行查询加持更大JSON半结构化一般很好PG的JSONBGIN索引比MySQL的JSON成熟得多地理空间/时序弱需依赖扩展很好PostGIS、TimescaleDB等扩展生态强大数据一致性/崩溃恢复良好很好PG的WAL与同步流复制机制更精细运维生态/招人难度很好一般MySQL资料多、托管成熟PG需要一定程度自我建设这张表不算什么“权威结论”但它是我做了大量对比后比较确定的经验总结。接下来两章我会把PG为什么在复杂场景下更强、MySQL到底强在哪里又弱在哪里分别讲透。2. PostgreSQL的性能底牌底层机制决定了它在复杂查询上的优势PostgreSQL很多看起来很能打的特性并不是靠堆配置堆出来的而是从底层数据结构设计上就占了便宜。不理解这些机制你就不知道什么时候该用它更不知道它哪些地方其实是短板。2.1 MVCC实现差异为什么PG的读不依赖回滚段高并发下反而更稳先讲多版本并发控制。MySQL InnoDB和PostgreSQL都自称基于MVCC但实现思路截然不同。MySQL InnoDB把旧版本数据放在undo log回滚段里行记录上有DB_TRX_ID、DB_ROLL_PTR等隐藏列。一个读事务需要根据当前ReadView去回溯undo链找到自己可见的版本。这套机制的优点是在低并发、短事务场景下非常灵活B树里只保留最新版本页面更紧凑。缺点也很明显一旦出现长事务undo链越来越长回滚段膨胀得快读到链尾的代价越来越大清理事务还要等待旧事务结束才能释放。PostgreSQL的MVCC则是把旧版本留在数据页里——每行有多个tuple版本通过xmin/xmax等事务ID字段标记可见性。读操作只需要检查事务ID和可见性位就能直接判断当前行可不可见完全不需要去一个链上回溯。这意味着什么呢在典型的长查询高并发写入混合场景下PG的读事务不会因为历史版本链变长而拖慢速度写事务也不会因为正在被读而阻塞。真正做到了读不阻塞写、写不阻塞读。当然这个机制也有代价。旧版本留在页面里会变成dead tuple带来表膨胀问题依赖autovacuum去清理。我见过很多PG上线初期没做好vacuum参数结果表膨胀了3倍查询性能反而比MySQL还差。这个坑我在第五章会详细讲。从MVCC这个维度看结论其实很清楚了如果你的数据库里经常跑大查询同时业务还在持续写入PG的设计在并发稳定性上天然更有利。你的查询不会因为一堆并发更新而被迫去回溯一条很长的历史链。这就是高性能场景推荐的底层原因之一。2.2 索引类型与优化器PG的超集式设计给了复杂SQL更多底气MySQL在InnoDB里基本就是B树一家独大8.0支持了降序索引和函数索引对地理位置有R-tree实现但也仅此而已。你能通过索引加速的SQL类型非常有限。PostgreSQL则像一本索引百科全书B-Tree等值和范围查询还支持覆盖索引、NULLS NOT DISTINCT等细节。Hash等值查询可以做快速的哈希连接。GiST / SP-GiST地理位置、范围类型、全文检索PostGIS的底子。GIN适合JSONB、全文检索、数组包含等倒排场景。BRIN超大数据量表上的范围统计索引对时间序列类批量数据极其有效。更关键的不只是种类多而是部分索引和表达式索引的组合能力。比如一张订单表90%的查询都过滤statusactive这个条件MySQL只能给status列建一个普通索引里面包含所有数据PG可以建一个WHERE statusactive的部分索引体积缩小一个数量级查询扫描的代价自然更低。这种细节在复杂查询和超大表场景中的差距比大多数人想象的更明显。再看优化器。MySQL 8.0的优化器这些年进步很快引入了hash join、窗口函数、CTE也不再是当年那个只能处理简单关联的萌新。但平心而论它在多表关联、混合子查询、复杂IN/EXISTS转换上仍然会出现选错执行计划的问题需要DBA反复用STRAIGHT_JOIN或FORCE INDEX去人肉矫正。PostgreSQL的基于代价优化器结合更细粒度的统计信息处理十张表以内的复杂关联时整体更稳定。它还有GEQO遗传算法来应对二十张表以上的极端JOIN场景虽然不一定总能找到完美计划但至少不会直接放弃治疗。有一次我排查一个线上问题MySQL对一张700万行的表和一个3万行的临时结果集做关联mysql优化器选了嵌套循环而不是哈希连接跑了45秒。同样的表结构迁到PG它通过统计信息判断该用Hash Join1.4秒完成。这种差距不是参数能弥补的是架构差异决定的。2.3 并行查询、物化视图、CTE与窗口函数分析型SQL在PG里像开了外挂PostgreSQL的并行查询从9.6开始逐步成熟到16、17版本已经能覆盖顺序扫描、聚合、连接、排序等多种算子。这意味着一条复杂分析SQL只要不是太小PG会主动拆成多个并行worker协同执行充分利用多核CPU。MySQL在这块一直没有对标的完整能力。举一个我实际做过的查询优化案例一张800万行的流水表按用户ID和时间维度做窗口函数排名同时关联一张用户表和一张地区表。MySQL 8.0的执行计划里窗口函数只能基于排序后的单线程结果集运行整条SQL跑了9秒多。PG这边启用并行后同一逻辑的SQL跑到了1.8秒差距超过5倍。另外两个值得单独说的特性是CTE和物化视图。MySQL 8.0虽然支持了CTE但很多场景下只是语法糖优化器对递归CTE和层层嵌套CTE的处理能力有限。PG从12版本开始允许使用NOT MATERIALIZED控制CTE物化行为你可以在临时结果集要不要落盘之间做取舍。配合递归CTEPG能轻松处理树形结构查询、BOM展开这类复杂逻辑MySQL做起来就痛苦得多。物化视图则是一个经常被忽略的性能武器。报表类查询如果每次都现算成本极高。PG原生支持REFRESH MATERIALIZED VIEW CONCURRENTLY在后台刷新物化视图的同时不阻塞查询。MySQL没有原生物化视图只能靠业务层建临时表或者引入额外的ETL任务复杂度完全不在一个量级。2.4 别被功能强大冲昏头PG自己也是有限度的讲完优点我必须给你泼一盆冷水。PostgreSQL不是银弹它有几个你一旦忽视就必然吃亏的短板每连接一个进程PG的连接模型是fork一个进程一个空闲连接也可能吃掉好几十兆内存。默认max_connections100在高并发下根本不够用必须搭配PgBouncer连接池使用。如果直接硬上几千连接OOM不是闹着玩的。表膨胀前面MVCC留下的dead tuple如果清理不及时表物理体积会不断膨胀查询需要读更多页面性能断崖式下跌。vacuum参数必须提前规划。长事务的连锁反应一个长期不提交的事务会导致autovacuum无法清理其开始时间之后的dead tuple表越胀越大。这个问题在MySQL里也有类似体现长事务会卡住purge但PG的膨胀对性能和磁盘容量的影响更直观。统计信息陈旧PG优化器太依赖统计信息如果不开autovacuum_analyze统计信息长期不更新可能导致执行计划走向灾难。我见过有的项目关闭了autovacuum结果一条简单查询突然从100毫秒变成5秒钟。运维生态相对薄MySQL有Percona Toolkit、日臻完善的云托管、各类binlog同步工具而PG的周边工具pg_stat_statements、PgHero、pganalyze等虽然够用但很多需要自己搭招人时的熟练度也普遍低于MySQL。所以高性能场景推荐PostgreSQL这句话的正确打开方式是**在PG的机制优势能发挥作用、同时你能兜住它运维复杂度的前提下推荐。**如果团队连一个能看懂pg_stat_activity和pg_stat_statements的人都没有那还是先把基础运维工作补起来再谈选型。3. MySQL的优势地带与真实瓶颈不吹不黑的一次公平对比数据库选型最忌讳二极管思维。很多人一听PG强就觉得MySQL一无是处这是极其危险的。我平时跟团队说的第一句话永远是先承认MySQL过去和现在都解决了海量业务问题再去批判它的边界。3.1 简单点查与短事务场景MySQL InnoDB依然稳坐钓鱼台如果你的业务就是用户点击、主键查这行、更新那行事务短得要命那MySQL的InnoDB在很长一段时间内仍然是更省心的选择。为什么第一InnoDB的Buffer Pool管理非常成熟。MySQL把大部分内存预算都投入到页面缓存点查和短事务的命中路径极其清晰而PG的内存结构复杂还要区分shared_buffers和work_mem等不同用途配置要求更高。第二MySQL的复制链路与生态衔接极其顺滑。binlog对接Canal、Maxwell等工具可以把变更流直接打到数据仓库、Kafka几乎成为国内数据链路的默认标准。这一点PG的逻辑解码虽然也能做但成熟度和周边工具数量还有差距。第三MySQL单机性能在优秀的配置和合理结构下并不低。Sysbench点查压测中MySQL和PG并没有巨大落差个别短查询甚至MySQL更有优势。这意味着如果你的核心负载就是主键点查你换到PG也很难感受到翻天覆地的收益反而要承担迁移成本和运维学习成本。所以对于稳定、简单、标准OLTP的定位MySQL仍然值得留任。这也是为什么很多银行、支付、互联网核心交易系统到今天依然是MySQL主扛而不是无脑迁PG。3.2 真正让MySQL吃力的场景复杂关联、混合负载与复制延迟MySQL最怕的事我一直总结为三件第一一条SQL里关联表太多、逻辑太绕。8.0虽然有Hash Join但优化器对复杂查询的自觉性仍然不够。很多数据库管理员都有过用STRAIGHT_JOIN强制连接顺序的经历。在PG里优化器会自己算每种关联顺序的代价你很少需要手动干预。第二混合负载上来了它扛不住。让MySQL同时处理高并发交易和重型统计查询结果往往是两条复杂SQL把CPU打满所有点查跟着遭殃。PG的并行查询会把重SQL分摊到多个worker减少了单条SQL独占资源的概率当然需要配合资源组和任务管控。第三异步复制的延迟问题。MySQL原生复制是异步的主库压力大时从库跟不上的情况很常见。半同步复制虽然改善但会引入额外的等待开销。PG的同步流复制可以做到一个master节点的事务提交时至少有一个同步备库确认落盘这个机制在一致性要求高的场景里价值极高比如账务类、订单核心链路。切换和持续可用性也做得更成熟如pg_rewind、级联复制、逻辑复制等。一个我经常用来给客户演示的案例一张2000万行的交易表要按商户维度统计日营收、毛利率、重复交易占比还要跟商户维表左连接算地区命中率。这条SQL在MySQL 8.0上加了所有能加的索引还是在6-8秒徘徊同结构在PG 16里通过并行哈希连接窗口函数重写优化到900毫秒左右。这就是复杂查询维度肉眼可见的差距。如果你的业务里经常有这类SQLMySQL给你的只能是再优化SQL、再清缓存、再升级配置的循环PG才能跳出这个循环。4. 一套压测方案与真实数据把选择从感觉变成证据与其在网上看一百篇我用了PG之后性能起飞的文章不如自己动手压测。但压测绝不是拿sysbench随便跑个点查就下结论那样你会得出MySQL更强的错误判断。4.1 压测方案设计不要只压点查把业务共性晒出来我建议至少做两套测试**第一套标准OLTP基准。**使用Sysbench构造8到16张表每张表100万行测试短点查、短更新、短事务混合。这个场景比较的是当家底子结果通常两者差距在10%以内看看即可。**第二套业务查询基准。**从你的真实业务里抽10到20条最有代表性的慢SQL尤其是那些多表关联、聚合统计、窗口函数、子查询嵌套的语句。改造成标准数据集放到两种数据库里分别跑记录每条SQL的响应时间。这才是决定选型的关键证据。如果公司有TPC-H数据集也可以跑SF10约100亿行规模? 实际SF10是100GB规模来观察复杂查询能力。压测时还要注意参数对齐。我见过很多团队一边给MySQL调了一周的参数一边用默认参数跑PG然后得出结论MySQL强于PG这种对比没有意义。至少对齐以下项目版本MySQL 8.0.x、PostgreSQL 16或17都用当前稳定版。内存配置MySQL的InnoDB Buffer Pool和PG的shared_buffers按各自推荐比例设置PG建议shared_buffers为内存25%左右并设置合理的work_memeffective_cache_size设为总内存的50%-75%。并发数相同连接数建议用连接池压到相同有效并发。数据集同一份数据同一结构注意类型映射同一行数。4.2 一份有代表性的压测结果解读我曾经为一套业务系统做过三个月的数据硬件为双路E5、SSD、64GB内存操作系统CentOS使用Sysbench和一组混合业务SQL进行测试。严格意义上这不是被审计的基准但趋势非常有代表性测试项MySQL 8.0PostgreSQL 16结论Sysbench 64线程纯点查18300 QPS17600 QPS基本打平MySQL略高Sysbench 64线程短事务混合7800 TPS7400 TPS基本打平MySQL略高12条复杂业务SQL多表关联聚合平均5.6秒平均1.9秒PG优势明显最大一条差7倍窗口函数排名榜SQL全表排序9.2秒2.1秒PG并行查询优势突出JSONB条件查询1.4秒120毫秒GIN索引下PG完胜不要过度纠结具体数字它们在不同硬件、参数和数据库版本下会有波动。但规律很清楚短小SQL阶段MySQL依旧能和PG打得有来有回一旦进入业务复杂SQL维度PG可以把差距拉到三到五倍甚至更多。4.3 判读数据的正确姿势别盯着平均值看延迟分位和稳定性压测结果出来后我不建议只看平均QPS或平均响应时间。更值得关注的是P99延迟和抖动概率。复杂负载下PG的P99稳定性通常更好因为并行查询能摊薄单个大查询对整体延迟的冲击。MySQL在重查询到来时P99很容易被拖到十秒级别因为它没有有效的并行消耗手段。当然如果你的压测数据显示两者在点查上持平、在复杂查询上PG大幅领先而你的业务恰好复杂查询占了大头那么选型结论基本就出来了PostgreSQL。如果复杂查询占两成以下、纯点查占八成那换不换PG就不是一个性能问题而是生态迁移问题——留在MySQL并优化慢SQL可能更划算。5. 换库之前要看的账本迁移与运维里的真实坑如果前面的对比让你动了迁库的心思千万别急着mysqldump一把梭。我见过太多团队在PG测试环境很快这一步就拍板上线结果生产环境被vacuum和连接模型教做人。这里把我踩过的坑和常规文档里不写的心得整理一下。5.1 部署和核心参数PG不是装上就能自动飞快PostgreSQL的安装本身不难官方提供源码包、编译包、Docker镜像等。我平时最推荐两种方式一是二进制包EDB安装包或官方仓库二是Docker跑测试环境。比如在开发机上用docker run拉起一个16或17版本方便快捷但生产环境不建议直接裸容器跑数据至少要有持久卷和完善的备份恢复方案。装好之后如果你什么都不调默认配置是为兼容性服务的不是为性能服务的。我在实际项目里通常会先确认这些参数shared_buffers设为物理内存的25%左右。64GB机器我一般给16GB。再高不一定更高效因为PG有自己的缓存管理逻辑。effective_cache_size告诉优化器操作系统页面缓存大概有多少一般设为物理内存的50%-75%。这个不影响真实缓存只影响执行计划的成本估算但会让优化器更愿意选索引扫描。work_mem单个排序和哈希操作可用的内存。默认1MB太小复杂查询很容易落临时文件。我通常从64MB或128MB起步结合连接数谨慎调整因为它是每操作内存而不是全局内存并发高时乘数效应很大。max_connectionsPG每个连接一个进程默认100看着还行但如果业务并发大配合PgBouncer把连接池控制在50-100之间更稳妥。maintenance_work_memvacuum、CREATE INDEX等维护操作可用内存建议加到256MB到1GB提升建索引和清理速度。checkpoint_timeout和max_wal_size控制崩溃恢复时间和checkpoint频率。不调好PG容易出现周期性IO毛刺。autovacuum建议保持开启。臃肿的表、堆积的dead tuple是PG性能杀手需要靠它主动清理。监控方面强烈推荐开启pg_stat_statements扩展它记录每一条SQL的执行次数、总耗时、平均耗时、块读写等统计信息是定位慢SQL和异常抖动的一线工具。搭配pg_stat_activity实时看长事务和会话状态基本就能覆盖日常巡检需求。5.2 迁数据时的类型和行为差异清单这可能是整个迁移里最劝退的环节。MySQL和PG表面上都是关系型数据库但细节差异能整出无数幺蛾子。差异点MySQLPostgreSQL迁移时注意整数类型TINYINT / MEDIUMINTSMALLINT / INTEGER小整数字段需要映射避免溢出或精度误解自增列AUTO_INCREMENTSERIAL或IDENTITYPG推荐用GENERATED ALWAYS AS IDENTITY字符串VARCHAR字符集排序规则VARCHAR按字节/区域规则排序、比较、索引长度差异极大布尔TINYINT(1)习惯BOOLEAN原生条件判断从1/0改成true/false时间DATETIME / TIMESTAMPTIMESTAMP / TIMESTAMPTZ强烈推荐用TIMESTAMPTZ否则时区全是坑JSONJSON类型JSONB类型性能差距巨大PG侧建议直接JSONB更新冲突ON DUPLICATE KEY UPDATEINSERT ... ON CONFLICT DO UPDATEREPLACE INTO要改成ON CONFLICT字符串连接CONCAT() / 直接加号|| 操作符习惯性语法错误重灾区LIMITLIMIT n OFFSET m同样支持基本兼容大小写表名/列名不敏感取决于配置未加引号标识符折叠为小写防止迁移后找不到列还有一些行为差异比如MySQL的NOW()返回当前会话时间PG的now()返回事务开始时间如果要当前真实时间点得用clock_timestamp()。MySQL对group by的容忍度较高PG严格按标准语法来SELECT列表中未参与聚合的列必须出现在GROUP BY或聚合函数内这些转换细节在代码评审时都要过一遍。好在有强力的迁移工具比如pgloader。它一条配置命令就能把MySQL的表结构、数据、主外键都搬到PG减少手工写转换脚本的痛苦。但工具只是第一步迁移后的数据全量比对和业务回归测试绝不能省。5.3 什么情况下坚持MySQL也不用后悔我必须把话收在这里免得有些人看完前面就盲目换库。以下情形我支持你继续留在MySQL业务99%是主键点查和短事务复杂SQL一年出现不了几次。团队对MySQL的运维经验和监控体系非常成熟对PG毫无积累。强依赖binlog生态比如Canal同步到大数据平台、数据湖、异构存储。PG虽然有逻辑解码但围绕binlog的中间件生态远不如MySQL丰富。云厂商托管实例已经帮你把MySQL的备份、监控、高可用都包圆了你的团队没有精力自建PG运维体系。我记得一次交流时有个架构师说我知道PG强但我们目前的业务配不上它的强引入它反而增加系统复杂度。这话虽然糙但非常真实。技术选型从来不是选最强的而是选最合适的。写在最后算是我的一个真实体会我自己的使用习惯是两边都留着。MySQL继续支撑那些极其简单的核心点查链路PG负责复杂报表、统计分析、半结构化数据、地理空间这类MySQL干起来很痛苦的活。两套数据库并存每个都只做自己最擅长的事运维成本虽然高一点但业务性能和系统稳定性都得到了保障。如果你现在正纠结要不要从MySQL迁到PostgreSQL我唯一的建议是先别听任何人下结论把你线上最重、最复杂的几条SQL抽出来放在同等资源的两套数据库里跑一遍用几分钟到几小时的压测换取选型的确定性。数据会告诉你答案而且这个答案往往比网上的论战可靠得多。