PostgreSQL vs MySQL——企业数据库选型我从使用者的角度说点大实话项目组上个月做新平台选型技术评审会开了两轮前端、后端、DBA、运维各执一词吵到最后变成了“PostgreSQL 还是 MySQL”的站队问题。其实每个做企业应用的团队都会走到这一步我过去几年两个数据库都用得很深从 500 万行的 MySQL 分表拆库到 20 亿行的 PostgreSQL 分区表分析库都有生产案例。这篇不列官方文档式的参数对比从我实际选型和踩坑的角度聊一聊这两个数据库到底差在哪、各自适合什么场景、以及做决定时需要考虑哪些不直观的因素。先给出全文坐标如果你做的是互联网高并发读多写少、以简单查询为主的业务MySQL 依然是最稳妥的选择如果你的业务涉及复杂关系查询、数据完整性要求高、需要 JSON 文档能力、想要减少中间件依赖PostgreSQL 的现代特性会明显提升你的开发效率。两个数据库在企业级保障能力上都已经非常成熟真正决定选型的往往是“团队技术栈”和“业务数据形态”这两个隐藏变量。1. 两种“正确性”的分歧从设计哲学理解选型本质命令行敲两句SELECT now();看不出什么区别但深入体系之后会发现MySQL 和 PostgreSQL 的底层设计哲学有根本分歧。这个分歧可以用一句话概括MySQL 优先考虑“足够好且快”PostgreSQL 优先考虑“严谨且标准”。1.1 MySQL 的乐观与轻量从 Web 时代长大的务实派MySQL 最初服务的是 Web应用、内容管理这类读远多于写的场景。它的 InnoDB 存储引擎做了大量针对高并发简单查询的优化比如自适应哈希索引、插入缓冲Change Buffer、聚簇索引直接按主键组织表数据。这套设计决定了它在短小精悍的 OLTP 查询上能拿到很漂亮的吞吐量数据。它对待 SQL 标准的态度也比较务实——能用就行不标准的语法日后慢慢补齐。比如 MySQL 很早就支持INSERT ... ON DUPLICATE KEY UPDATE这种特有语法但直到 8.0 才支持窗口函数MySQL 8.0 之前连都ROW_NUMBER()都没有直到 8.0.17 之前GROUP BY的做法也和标准行为不一致非聚合列可以被直接查出且结果不确定。这种“先满足需求、后对齐标准”的路线让 MySQL 在很长一段时间内占据了 Web 开发者的心智。在实际使用中还有一个很直观的例子MySQL 在建表时如果指定了TIMESTAMP类型的列它会自动把第一列设为NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP取决于版本和explicit_defaults_for_timestamp参数这个默认行为一度让很多迁移过来的开发者困惑。MySQL 觉得这样“用户省事”PostgreSQL 会觉得“隐式行为就是埋雷”。1.2 PostgreSQL 的学院派执着把关系数据库该做的事做完PostgreSQL 的源头可以追溯到加州大学伯克利分校的 POSTGRES 项目血统里带着研究型数据库的气质完整支持外键、检查约束、非空约束、唯一约束是底线触发器、规则系统、自定义类型、自定义函数支持 PL/pgSQL、PL/Python、PL/Perl 等、继承表、部分索引、表达式索引这些东西从很早期就是标配。它对待 SQL 标准是真正的“较真”。以我踩过的坑为例PostgreSQL 对NULL的处理极其严谨三值逻辑TRUE/FALSE/NULL、NULL 排序默认排最后、UNIQUE约束默认不限制 NULL 重复——这些都是标准行为但刚从 MySQL 转过来的同事十个人里有九个会懵。PostgreSQL 的文档里专门有一章讲“数据完整性”从约束、触发器到规则系统层层递进这体现了它对“数据正确性”的重视远高于对“语法友好”的重视。它们的性能路线也有本质差异InnoDB 的 MVCC 依赖undo log和回滚段更新频繁时索引碎片和 undo 膨胀是运维常客PostgreSQL 的 MVCC 则是通过多版本行数据新旧版本行并存于堆表中实现的配合VACUUM清理死元组。这套机制的代价是要花心思调autovacuum收益是它在多版本并发控制下不容易出现像 MySQL 那样的历史版本链过长问题长事务对整体性能的拖累相对可控。这两种哲学没有对错但它们决定了同一句业务 SQL 在两个数据库里会得到什么结果、以什么性能得到以及出问题时你会面对什么样的排查复杂性。选型之前先想清楚你的业务是“绝不允许数据错”还是“偶发小错可容忍、响应要快”这个偏向几乎直接给出答案了。2. 日常开发最容易感知的差异SQL行为与数据完整性业务同学对数据库选型最直观的感知就是写 SQL 的时候顺不顺手、表结构设计能不能按真实业务去建。这里我把日常开发里最常遇到的行为差异总结一下下面这几条是我在做技术分享时每次都会讲的。2.1 数据类型与索引能力文字上都在细节里全是坑双方都支持 INT、VARCHAR、TEXT、TIMESTAMP、JSON但你用起来会发现“同一个名词”背后的行为完全不同自增列MySQL 是AUTO_INCREMENTPostgreSQL 是GENERATED ALWAYS AS IDENTITY9.6 之前是SERIAL。PG 的 IDENTITY 是标准 SQL 写法而且GENERATED ALWAYS模式禁止你手动插入该列值对数据完整性明显更友好MySQL 的 AUTO_INCREMENT 在重启、回滚后序列不连续非常常见这只是表象问题真正的差异在于 PG 的序列是独立对象你可以一个序列给多表共用也可以额外控制序列的缓存和步长灵活度高出不少。字符串类型MySQL 的VARCHAR(255)里 255 是字符数还是字节数取决于列字符集utf8mb4下是字符数早期utf8下曾经有坑而且VARCHAR有 65535 字节的行大小限制PG 的VARCHAR(n)限制的就是字符数TEXT类型则完全没有长度上限。真要存长文本PG 的 TOASTThe Oversized-Attribute Storage Technique机制会把大字段单独压缩存储不会把整行撑爆。JSON 能力MySQL 8.0 的 JSON 类型和 JSON 函数JSON_EXTRACT、JSON_SET、JSON_CONTAINS已经够用了但它不支持 JSON 字段内部的索引只能通过生成列建虚拟索引绕道PostgreSQL 的 JSONB 支持 GIN 索引可以直接对字段内的 key 做等值、范围查询配合、?、?|这些操作符文档存储的体验非常接近 MongoDB。我在物联网项目中用 JSONB 存设备上报的动态属性字段查询性能完全在线省掉了一层文档数据库的调用。2.2 约束、触发器与并行写入数据一致性的“严格程度”是代差外键、检查约束和触发器是两个数据库都有的能力但行为边界差异很大PostgreSQL 的约束检查默认是立即执行NOT DEFERRABLE或INITIALLY IMMEDIATE但支持DEFERRABLE INITIALLY DEFERRED——把外键检查推迟到事务提交时。这意味着你可以先插子表、再补父表数据在批量导入和复杂数据清洗时非常省事。MySQL 的FOREIGN_KEY_CHECKS0也能临时关闭外键但这种一刀切的体验远不如 PG 的细粒度延迟约束优雅而且 MySQL 关闭外键检查期间破坏了引用完整性后续开启时并不会校验已有数据是否仍然合法。MySQL 的触发器有一些先天限制同一张表的同种触发事件BEFORE/AFTER只能各定义一个触发器5.7 之前是每个事件只能一个8.0 放宽到每个事件每个时机各一个但依然绑死在表级别PG 的触发器可以用行级、语句级、INSTEAD OF视图上也能建触发器可以按条件触发CREATE TRIGGER ... WHEN (condition)控制力完全不是一个量级。写并发和数据一致性上两个数据库处理脏读、不可重复读、幻读都是通过不同手段MySQL 靠 undo log 锁 间隙锁实现可重复读RRPostgreSQL 靠快照隔离SI 升级到 SSI实现可串行化快照隔离。关键区别是PG 的默认隔离级别是 Read Committed而它的 Read Committed 行为已经比 MySQL 的默认级别RR更贴近直觉同时 PG 的可串行化隔离级别提供了真正的SERIALIZABLE保证。在高并发账务类场景直接开 PG 的 SERIALIZABLE 不必担心丢更新MySQL 的 RR 则偶尔会出现application-level 的“先查后改”被并发覆盖问题需要你额外加FOR UPDATE或悲观锁兜底。2.3 全文检索与扩展能力从“够用”到“可用”MySQL 的全文索引只支持 MyISAM 和 InnoDB 的FULLTEXT中文分词基本不可用实际项目里搜索都是另外接 ElasticsearchPostgreSQL 的全文检索tsvector/tsquery是内置的支持词典、同义词、高亮、权重配合 GIN 索引中文语料也能做成轻量级站内搜索中小型系统不必为了一个搜索框就引入 ES 集群。另外 PG 的pg_trgm模块可以做模糊匹配的索引加速btree_gin可以给普通 B-tree 字段建 GIN 索引来加速多列组合查询这些都是 MySQL 不可能给你的。思考题如果你的业务有一个需求是“在一张 5000 万行的大表上对三个普通字段加一个联合搜索且只按相关性排序返回前 50 条”MySQL 的普通索引和LIKE %xx%性能一定让你头疼PG 的组合 GIN 索引则能轻松扛住。这就是我在实际选型里不停纠结“要不要多上一种中间件来补短板”的原因。3. 部署、高可用与迁移成本运维视角的真实对比选型不是开发一锤子DBA 和运维的支持度直接影响上线后系统的稳定性。以下是我从实际运维两套系统中积累的体感按部署复杂度、高可用、迁移工具和社区生态拆开看。3.1 部署和日常运维MySQL 的“开箱即用”与 PG 的“精调收益”MySQL 确实是“装完就能跑”的典型——YUM/Apt 源一配systemctl start mysqld几分钟内拿个登录口令就能建库。PostgreSQL 的官方安装包在不同发行版上略有差别Ubuntu 用 APT、CentOS/Rocky 用 DNF、Windows 用 EDB 安装包热搜词里的 “postgresql 12 windows 离线安装包” 就是这个但 PG 安装完成后的pg_hba.conf、postgresql.conf、postgresql.auto.conf三件套比 MySQL 的my.cnf清晰得多配置项注释详尽到像一本教科书。安装上有几个容易踩的点初次连接 PG 时默认只监听localhost需要改listen_addresses同时还要在pg_hba.conf里加一条应用服务器 IP 的host规则。很多人第一次部署 PG 卡在“连接被拒”很久其实就这两个地方。PG 的data目录权限要求很高如果启动失败先去日志里看是不是目录 owner 不对chown给postgres用户即可这个细节在linux 安装 postgresql的热搜里能排上前三的坑。Docker 部署热搜里的docker-compose: postgresql的话注意给 PG 挂数据卷时必须指定PUID/PGID和对应 permission否则容器重启后数据目录可能没有写入权限这个坑坑过不少用docker run -v图省事的人。日常维护上最大的体感差异是膨胀管理MySQL 的 InnoDB 表空间和 undo 表空间大小增长主要靠optimize table、重建表来回收PG 则需要有意识地维护autovacuum参数autovacuum_vacuum_scale_factor、autovacuum_analyze_scale_factor配合大表的pg_repack做在线收缩。如果前端代码里大量长事务、频繁 updatePG 的pg_stat_user_tables里n_dead_tup会很快涨起来不处理就会走全表扫描出现“数据量没涨多少查询突然变慢”的玄学。我的经验是对 100GB 以上且更新频繁的 PG 大表手动调低 scale_factor 到 0.01 甚至用(n_dead_tup 阈值) OR (比例 阈值)双重触发条件能明显缓解膨胀。3.2 高可用与同步方案从复制原理到真实拓扑MySQL 的高可用主流方案是主从复制 MHA/Orchestrator或者 8.0 之后继续用 Group ReplicationMGR。MySQL 复制本质上依赖 binlogROW 格式半同步复制在 5.7 之后性能损耗已经可接受但 MHA 的 failover 机制本质是“尽力而为”极端场景有脑裂风险MGR 对网络要求又非常苛刻单写模型在大规模写入下延展性受限。PostgreSQL 的高可用方案集中在 Patroni热搜词里正好有postgresql高可用patroni安装。Patroni 使用 etcd/Consul/ZooKeeper 做分布式共识选主管理 PostgreSQL 流复制并在主库故障时自动提升备库。我这里简单给一个最小可用的 Patroni etcd 架构认知每个 PG 节点上跑一个 Patroni 进程统一管理这个节点的 Pg 启动、监控和故障恢复Patroni 通过 etcd 集群的 lease 机制竞锁决定谁是主、谁是备主库挂了etcd lease 过期后剩余备库通过选举产生新主应用连接通过 Patroni 的 REST API 去发现主库地址Patroni 还能管理pg_hba.conf的同步更新连接串会直接指向当前主节点。如果你的企业已经有 KubernetesPG Operator比如 Zalando Postgres Operator和 CloudNativePG 这些方案也能把 PG 集群全托管在 K8s 里日常扩缩容、备份、高可用都由 Operator 编排运维成本比传统虚机方案低不少。但先提醒一句K8s 化部署 PG 不适合数据量极大或对性能极其敏感的场景容器网络和本地盘 I/O 的开销会吃掉一部分性能红利。迁移方面MySQL 转 PG 的工具有pgloader处理表结构、数据、索引、外键一股脑搬PG 转 MySQL 就要自己写脚本或者用mysqldump转换器过程比较痛苦。结构对比有migraPython 写的支持 PostgreSQL 与 MySQL 之间的 schema diff 输出迁移脚本这个我在跨库数据同步时用过能很好地对齐两边表结构的差异比mysqldump配上人肉 review 高效得多。3.3 许可证、社区与其他生态的隐性成本MySQL 的双授权和组件分裂是很多企业内部评估时要掂量的问题Oracle 主导的 MySQL 本身是 GPL 协议但它的部分组件原本是独立协议比如 MySQL Cluster 的 NDB后来 8.0 里一些功能开始向商业版倾斜比如mysqlbackup增量备份、防火墙功能MariaDB 是社区分支但连接协议、授权方式和 Oracle 版本已经出现细微分叉你网上搜到的一些命令可能在某些发行版上是 GNU 版才有的。PostgreSQL 采用的是类 MIT 的开源协议PostgreSQL License不用考虑商业授权、不用关心社区分支分裂这一点在企业合规和长期技术路线上其实非常关键——我见过团队因为 MySQL 某个组件从开源版挪进商业版而被迫改架构的案例PG 让我省掉了这种担忧和重新评估成本。4. 性能问题的正确打开方式别让“谁更快”误导选型网上铺天盖地的“PG 比 MySQL 快 30%”“MySQL 读写性能碾压 PG”这类结论基本都是在特定负载下的片面解读。我的真实测试经历里两者的性能差异远比想象中依赖场景。4.1 OLTP 基准下的理解读多写少 MySQL 占优复杂写 PG 更稳从 TPC-C 类基准测试例如 Sysbench看纯读场景SELECT点查范围查MySQL 由于 InnoDB 的二级索引 自适应哈希索引在大量并发短查询下能拿到更高的 QPS。但是一旦查询变复杂——三张表 JOIN 带 GROUP BY、子查询带窗口函数、或者加入 JSON 过滤条件——PostgreSQL 的查询优化器基于代价估算的 CBO通常能生成更优的执行计划执行时间往往反超 MySQL。这个现象在mysql架构与mysql 原理的相关材料里也能找到佐证MySQL 的优化器在单表简单查询上很激进复杂查询的执行计划选择往往不如 PG 精细比如多表关联时对 hash join 的代价估算不如 PG 准确。我在一个数据仓库离线同步场景里把一条需要关联 5 张表、加两个CASE WHEN和ROW_NUMBER()的报表 SQL 从 MySQL 迁到 PG执行时间从 27 秒降到 4 秒没有改任何索引和表结构。原因是 MySQL 对窗口函数的实现早期需要引入临时表做全量排序PG 则能直接利用排序节点配合窗口帧计算。4.2 连接数和并发写一个经验之谈PostgreSQL 采用每连接一进程模型1000 个并发连接时单机内存开销比 MySQL 的线程模型大不少。所以用 PG 必须引入连接池PgBouncer 或应用侧连接池不然连接数一多CPU 光花在进程切换上。MySQL 的线程池则对短连接更宽容一些但这不代表 MySQL 不需要连接池——高并发下连接数的开销同样惊人。从并发写角度看PG 的 HOTHeap-Only Tuple更新机制在“更新非索引列”时能极大降低索引维护开销配合fillfactor预留空间高速更新写入场景的膨胀控制得当性能并不会输给 MySQL。我的一个支付系统里每日流水表约 3000 万行持续 8 小时高峰写入PG 在fillfactor70 合理 autovacuum 配置下P99 写入延迟能稳定在 10ms 以内这刷新了我对 PG 高并发写入的老观念。4.3 分区表从 5.7 的干将到 PG 的原生支持MySQL 的分区表RANGE/LIST/HASH在 5.7 时代限制很多分区键必须包含在主键里、无法自由定制每分区的表空间、查询优化器对分区的裁剪经常失效。MySQL 8.0 的分区功能有所改善但依然不支持按照表达式分区也不支持外键引用分区表。PostgreSQL 从 10 版本开始引入声明式分区11 版本大幅改进分区裁剪性能13 版本支持BEFORE ROW触发器在分区表上使用。我现在在生产环境用 PG 的分区表做时序数据每天自动创建新分区配合pg_partman做分区管理和自动清理查询裁剪准确率极高维护成本远低于 MySQL 时代的ALTER TABLE ... PARTITION手工操作。如果你有大量历史数据需要按时间归档和过期清理PG 的分区能力是实打实的效率提升。5. MySQL思维迁移PostgreSQL的十二个常见坑从 MySQL 转到 PG 最容易踩的坑我在团队内训里总结了 12 条每一条都是从真实事故中提炼的发布出来方便大家避坑。坑位MySQL 习惯迁移到 PG 的正确做法自增主键插入INSERT INTO t (id, ...) VALUES (1, ...)使用GENERATED ALWAYS AS IDENTITY的列禁止手工插入改成OVERRIDING SYSTEM VALUE或使用普通SERIAL字符串大小写MySQL 默认utf8mb4_general_ci不区分大小写PG 默认_en_US.UTF-8的 collation 区分大小写唯一键/查询条件要注意大小写NULL 排序MySQLORDER BY col ASC时 NULL 排最前PG 默认 NULL 排最后需要用NULLS FIRST/LAST显式控制NULL 唯一约束MySQL 的 UNIQUE 索引允许多个 NULLPG 的 UNIQUE 约束默认允许 NULL 重复若要“只有一条非空”需建部分唯一索引CREATE UNIQUE INDEX ... WHERE col IS NOT NULLON DUPLICATE KEY UPDATEMySQL 自带PG 用INSERT ... ON CONFLICT (col) DO UPDATE SET ...注意ON CONFLICT要求冲突列上有唯一约束/索引LIMIT offset, countMySQL 写法PG 用LIMIT count OFFSET offset且深度分页建议keyset pagination索引前缀MySQL 支持INDEX(col(10))PG 不支持普通索引前缀改用表达式索引CREATE INDEX ON t ((left(col,10)))GROUP BY宽松模式MySQL 5.7 默认关闭ONLY_FULL_GROUP_BY可以查非聚合列PG 严格遵循 SQL 标准非聚合列必须全部出现在GROUP BY中或者用DISTINCT ON跨库查询MySQL 可SELECT * FROM db1.t1 JOIN db2.t2PG 一个数据库内部直接查跨数据库需dblink/postgres_fdw或提前拆库设计布尔类型MySQL 的BOOLEAN是TINYINT(1)别名PG 有原生boolean但注意 PG 引擎内 true/false 不能直接和 0/1 做算术运算全文本搜索MySQL 的 FULLTEXT 对中文基本无效PG 的to_tsvector(simple, ...)配合中文分词插件如 zhparser可做站内搜索隐藏字符MySQL 的VARCHAR尾部空格默认不比较PG 会严格保留并比较尾部空格LIKE和唯一键判断结果可能和 MySQL 完全不同这 12 条背后都有一个共性MySQL 为了易用性做了很多宽松处理PG 为了正确性做了很多严格处理。团队切换数据库最大的成本其实不是数据迁移而是所有写 SQL 的人都要进行一次“严格性”的思维升级。5.1 再说一下 SQL 标准贴合度带来的语法迁移成本热搜里有一条是oracle和postgresql语法区别说明很多企业在从 Oracle 向 PG 迁移。实际上 PG 的 PL/pgSQL 和 Oracle 的 PL/SQL 有相似之处比如都支持$$美元引用、命名块、异常处理。PG 甚至可以通过orafce扩展模拟 Oracle 的许多内置函数SYSDATE、DUAL、TO_CHAR等这让 Oracle 老项目的迁移平滑度比想象中高不少。MySQL 的存储过程、函数语法和 PG 相比差异较大存储过程里 MySQL 用DELIMITER分割语句块PG 用DO $$ ... $$MySQL 支持DEFINER权限模型PG 更多依赖SECURITY INVOKER/DEFINER函数属性MySQL 的变量是varPG 的在 PL/pgSQL 里直接声明DECLARE var int;使用时直接写var。这两个体系带给开发者的心智负担是完全不同的级别迁移时不能光跑脚本。5.2 数据迁移应该怎么做从方案到验证如果已经决定要从 MySQL 迁到 PG或者反过来我的建议顺序是评估语句兼容性把业务库的慢查询日志、核心 SQL 拿出来逐条 REVIEW 是否有重写需求。写一套方言兼容层在 DAO 层抽象 SQL 模板避免直接 SQL 满天飞能省下大量后期返工。结构迁移用pgloader加载已有库表结构再用migra生成差异脚本人工核对约束和索引差异。数据迁移pgloader可以并行导入压测时多开几个 worker注意 PG 侧提前调大maintenance_work_mem和max_wal_size让导入更快。灰度切换先跑双写或准实时同步用pg_chameleon这类工具把 MySQL 变更实时同步到 PG等应用层切流验证无误后再完全停掉 MySQL 实例。热搜里的postgresql数据库同步软件正好覆盖这个场景除了pg_chameleon还有基于逻辑复制的Debezium生态也能做数据库 CDC。迁移过程最容易被低估的是字符集和排序规则MySQL 的utf8mb4和 PG 的UTF8在排序上表现不同很多应用在迁移后出现排序结果变化最终只能通过在查询里显式指定COLLATE来修正。这类隐性问题建议在迁移前的“兼容性测试”阶段就覆盖到位。6. 给团队的一个务实决策矩阵很多选型文章喜欢在最后下结论“选 MySQL”或“选 PG”但做技术决策最怕的就是一句结论替代所有上下文。我列一个基于业务形态的决策矩阵供大家直接抄作业业务形态推荐数据库核心理由标准互联网 Web 应用用户、订单、内容、日志MySQL生态完善、开发资源充足、读写分离和分库分表资料成熟金融、账务、订单中心、库存强一致场景PostgreSQL数据完整性、可串行化隔离、约束和触发器能力强复杂报表、多表 JOIN、数据仓库贴源层PostgreSQLCBO 优化器更强、窗口函数/CTE/LATERAL 齐全、支持列存扩展citus、timescaledb物联网/时序数据PostgreSQL TimescaleDB原生分区时间戳索引连续聚合避免额外搭建 TSDBJSON 文档为主的业务PostgreSQLJSONB 或 MongoDBJSONB 支持 GIN 索引减少异构存储门户/内容管理系统读多写少MySQL简单查询吞吐高、生态工具多FastAPI/Spring Boot 开发体验好极大规模 OLTP千万级 TPS两者都不是最佳方案考虑分布式数据库TiDB、OceanBase或者把事务约束收窄到分区内已有大量 PL/SQL 存储过程的 Oracle 老系统PostgreSQLoracle 迁移兼容性经 orafce 扩展改善且开源无需授权需要考虑的另一个隐藏因素是团队技能栈如果你的团队全员 MySQL 出身且业务复杂度和数据量没有到需要 PG 特性的程度强行切换的隐形成本可能超过收益。反过来如果团队已经在用 Spring Data JPA 这类 ORM它对 PostgreSQL 的方言支持同样完善切换门槛会低很多。7. 我的实际选型心路与一个小建议我已经把选型话题拆得比较透了最后想结合几次实际项目经历多说两句心路层面的事。有一次我们做统一登录认证中心用户表加 session 表大概 2000 万行接口都在毫秒级MySQL 用的很舒服直到后来要做基于细粒度权限矩阵的复杂关联查询并把权限变更做成实时鉴权MySQL 的 JOIN 和级联更新能力开始捉襟见肘我们被迫在应用层做权限缓存、增加额外冗余表来规避复杂查询。后面重构时用了 PostgreSQL权限模型直接按关系表做规则引擎生成 SQL整个权限判断链路清晰又高效这个反差让我意识到如果你的业务有“复杂关系”这个前提MySQL 的开销会从数据库本身转移到应用层而 PostgreSQL 能帮你把复杂度留在它最该在的数据库层。有一个建议我想特别强调选型时别只看“现在”要看“未来两年业务会怎么长”。特性需求、数据量增长、复杂查询比例、团队是否要支持时序数据/JSON——这些比“今天TPS多少”更能决定哪个数据库让你少折腾。我的经验是宁可多花半个月做兼容性调研和原理解读也别因为“同事熟 MySQL”就草率启动一个要用七八年的核心系统。另外如果组织里有条件让 DBA 和核心开发每人花三天时间把另一个数据库的实际案例至少包括安装、备份恢复、主从切换演练跑一遍再开选型决策会。手里有实操感受比背一百条论坛结论都管用。两个数据库都是二十多年的成熟项目谁也不是玩具选出来的方向只要是基于业务本质和技术组织能力评估就是合适的答案。
