MySQL还是PostgreSQL：选型不能只看跑分

新项目选 MySQL 还是 PostgreSQL，没有脱离业务负载的统一答案。如果团队已有可靠的 MySQL 运维流程，业务主要是常规事务读写，它可以成为起点；如果关键流程涉及复杂查询或对事务内读取结果有明确要求，就应把 PostgreSQL 放进同一轮验证。最终选择要同时满足业务语义、负载目标和团队的维护能力。

一次单机 CRUD 跑分不足以替这个决定拍板。两者的默认事务隔离级别不同，客户端连接在服务端的处理方式也不同。测试没有交代事务边界、连接复用和查询形状时，“更快”只能描述那组测试条件，不能直接推断真实业务的并发结果。

默认隔离级别会改变事务读到的数据

MySQL 8.4 的 InnoDB 隔离级别文档列出的默认值是 REPEATABLE READ：同一事务中的普通非锁定 SELECT，沿用首次一致性读取建立的快照。锁定读取以及 UPDATE、DELETE 有各自的读取和加锁行为，因此不能把普通 SELECT 的快照规则推广到事务内所有语句。

PostgreSQL 的事务隔离文档列出的默认值是 READ COMMITTED；在该级别下，普通 SELECT 读取语句开始前已提交的数据。同一事务内相继执行的 SELECT，可能因并发提交而看到不同结果。PostgreSQL 接受 READ UNCOMMITTED 设置，但其实际行为仍按 READ COMMITTED 处理。

设想一笔订单先被事务 A 读取，事务 B 随后修改订单状态并提交，事务 A 再次执行普通 SELECT。按上述默认设置，InnoDB 的第二次读取仍使用先前的快照，而 PostgreSQL 的第二次读取可以看到新提交的状态。这是一个明确标出的条件示例，不代表所有读写组合都会如此；如果事务 A 改用锁定读取或执行更新，行为还要按相应语句判断。

这种差异直接关系到“读状态、作判断、再写入”的流程。选型前应说明流程允许事务内两次读取看到不同版本，还是必须维持同一读取视图；随后检查应用或连接池有没有显式设置隔离级别。比较默认配置有助于了解开箱行为，比较同一业务约束下的配置则更适合回答实际部署问题。

连接模型决定并发测试测到了什么

MySQL 的连接管理说明描述了客户端连接关联专用线程的模型：新连接可以复用线程缓存中的线程；MySQL Enterprise Edition 还提供服务端线程池插件作为另一种处理方式。连接数量增加时，线程所需的内存和调度资源也要计入容量评估。

PostgreSQL 的连接建立说明描述了客户端连接对应后端进程的模型，请求到来时由负责监听的进程启动相应后端。线程与进程的区别本身不能换算成吞吐排名；连接维持多久、同时有多少查询在执行，以及应用连接池如何限流，都会改变实测成本。

对短请求密集的服务，数据库里的连接总数与正在执行的查询数应分开看。若一边复用已有连接，另一边为每个请求重新建连，结果混入了不同的客户端策略；若只测已建立连接上的 SQL，又可能漏掉生产环境中的突发建连和排队。测试应使用计划投入生产的连接池设置，并同时观察连接等待、查询耗时与错误。

单次 CRUD 跑分为什么容易失真

MySQL 的性能测量指南区分安静系统上的单项操作测试与持续运行的工作负载测试，并指出性能优势可能随环境改变而反转。因此，按主键做插入、读取、更新和删除所得的成绩，只能说明这些操作在特定条件下的表现；它不能代替对关联查询、范围筛选、并发更新或连接高峰的测量。

缓存会明显改变短测试的含义。反复访问一小批记录时，数据页和索引页可能已在内存中；数据集扩大或访问热点改变后，存储访问占比也可能改变。同样叫“读取”，按唯一键取一行与筛选、排序后返回一页记录，访问路径和资源需求并不相同。比较时应固定业务输入与结果要求，同时允许两套系统采用各自合理的索引和 SQL 写法。

吞吐与响应时间也要放在一起解释。平均延迟可能掩盖高负载时持续排队的请求；P99 是请求耗时的第 99 百分位，用来观察较慢的一端，而不是最快请求的速度。如果某个配置提高了每秒完成的事务数，却让业务关键接口的尾部延迟、超时或重试超过可接受范围，这项吞吐优势就不足以决定选型。

一份可以重跑的选型基准应包含什么

基准要让另一名工程师凭数据生成方法、参数、配置和查询脚本复现主要结果。下面的记录项既适用于两套数据库之间的比较，也适用于日后更换版本或调整配置后的复测。

数据与业务输入：列明表结构、索引、行数、数据体量、键值分布和热点比例。说明负载来自哪类真实流程，例如订单状态更新、列表筛选或多表汇总；无法取得生产分布时，把生成规则和假设写清楚。
硬件与部署：在实验表中列明所用软件版本、处理器、内存、存储介质、网络路径及部署拓扑。两边分配等价资源，并注明压测客户端是否与数据库争用同一台机器，以便辨认客户端和网络瓶颈。
缓存与配置：分别说明数据是否经过预热、预热如何进行，以及测试前是否清理缓存。保存连接池、内存、日志持久化、隔离级别、自动维护及复制相关设置；为某一方做过的调优也要随结果公开。
查询与事务：给出各类 SQL 的参数范围、返回行数、读写比例、索引设计和提交边界。核对两边返回相同业务结果，并保存执行计划；语法可以不同，但一方不能少做校验、少写数据或跳过必要的持久化步骤。
负载与指标：先在稳定到达率下测常态负载，再逐级提高压力，直到排队、错误或延迟出现明显变化。每档保存持续时间、连接数、已完成事务数、吞吐、P99、超时、锁等待和重试情况，而不只保留最高吞吐值。
重复与波动：按同一流程运行多轮，保留每轮结果和异常。若排序随着缓存状态、查询比例或少量配置调整而变化，应写出这些条件，并定位瓶颈；挑选表现最好的一轮无法说明日常负载会怎样运行。

业务类型和团队经验如何改变选择

对于常规事务读写占主导、团队已经熟悉 MySQL 迁移、监控、备份和恢复的项目，沿用 MySQL 是有依据的工程选择：团队能够较快识别并处理熟悉的故障。若核心工作负载包含复杂筛选、关联和报表，则应把 PostgreSQL 放进优先测试名单，实测这些查询与并发写入同时发生时的表现。这是测试顺序的建议，不预设性能胜负。

如果关键流程依赖事务内多次读取，先确定可接受的并发结果，再验证应用实际使用的隔离级别及锁定语句。如果服务预计产生大量短连接，则把连接池、空闲连接和突发建连放进容量测试。备份恢复、升级与故障排查也应实际演练：跑分上的收益，需要与团队长期承担的操作成本一起衡量。

对新项目而言，可辩护的选择是那个在正确事务语义下满足目标负载、尾部延迟和恢复要求，并且团队能够持续维护的系统。可复现跑分是这项判断的证据；它的条件越贴近业务，结论才越有用。