在不同的云厂商购买相同规格的 MySQL 实例 (如 4vCPU-16GB)，获得的性能相同吗，他们的差异如何？本文继续尝试回答这个问题。
详细数据：
在本次测试中：阿里云 RDS MySQL 性能表现最好，极限的 QPS 达到了 4 万；其次是腾讯云，达到了 3.2 万；第二梯队是华为云、百度云和 AWS，极限的 QPS 约 2.2 万；之后是 Azure、Google 云，极限 QPS 约 1.2 万；最后是 Oracle 云，极限 QPS 约 8500。详细的数据和趋势图，可以参考以上的图、表，这里不再详述。
本次测试新增了“单位 CPU 计算能力”、“单位 CPU 上的 Sysbench QPS”等数值，可以更好得帮助开发者理解这些性能表现后的原因。
“单位 CPU 上的 Sysbench QPS”（Sysbench QPS per CPU Capacity Unit），很大程度上展现了各个厂商在该测试模型下，对 MySQL 内核性能优化的效果如何。
本次测试中，新增了“CPU 计算能力指标”，参考上图的“cpu_capacity”数据。“CPU 计算能力指标”，表示该实例的 CPU，在较高并发（等于或超过 CPU 核数 / 超线程）情况下，每秒能够完成多少万次简单的散列计算。例如阿里云的“CPU 计算能力指标”是 80.4，则表示该 CPU 平均每秒能够完成 80.4 万次简单字符串散列计算。
有了这个指标，我们可以对上述的性能指标再进行一次深入的观察：
首先，可以直观的看到，每个云厂商，提供的该标准规格下 CPU 资源具体为多少。这也就是上图中蓝色的柱状图。例如，这里的阿里云 RDS MySQL 的“CPU 计算能力”为 80.4，腾讯云为 93.3，华为云为 163.6。可以看到，各个云厂商对于“相同”（4c16g）的实例，提供了不同的 CPU 计算能力。而这些计算能力也在各个 RDS MySQL 的 Sysbench QPS 中有所表现。
更加深入的，还可以观察到每个云厂商在“单位 CPU 计算能力”所能够提供的 Sysbench QPS。这里，对“单位 CPU 计算能力”定义是：在 MySQL 中“一万次简单散列”的计算资源。上图中的红色柱状图，即表示“单位 CPU 计算能力”所能够提供的 Sysbench QPS。
因为该指标不再关注绝对 CPU 表现下的 Sysbench QPS，所以，该指标可以反映各个厂商在该测试模型下，对 MySQL 内核性能优化的效果如何。
当然，对于开发者选择 RDS MySQL 来说，有时候只关注绝对 Sysbench QPS 就可以了。
还需要注意的是，因为各个云厂商的架构、性能参数等各不相同，所以，在做对比的时候，需要考虑这些因素。例如，百度的 RDS MySQL 的 sync_binlog 参数是 1000，其他厂商都是 1；再比如，AWS RDS MySQL 使用的存储同步复制，所以默认情况下，Binlog 甚至是关闭的（准确的说，应该是与 automated backups 是否开启有关）。
在上一次测试：《全球八大云厂商，谁的 RDS MySQL 性能最强？》中详细的描述了如下问题：
本次测试这些内容并没有改变，这里不再赘述。
本次测试了杭州、北京两个地区 RDS MySQL，两个地区的实例性能相差比较明显：4 万 vs 3.2 万。并且，本次测试性能相比于之前的测试，性能增长明显。从这里的观察来看：
本次仅测试了腾讯云北京、独享实例，整体的性能表现依旧非常好。纵向的，与 5 月份的测试对比，性能较为稳定，没有太大的波动。值得注意的是，相比于之前（202405 上海区域），本次测试腾讯云的实例使用了更少的“CPU 计算能力”，但依旧获得了与之前测试较为接近的性能表现。
本次测试华为云表现稳定，与之前的测试表现非常接近：性能数据接近，版本几乎相同（build 号从“8.0.28-231002”升为了“8.0.28-231003”），所提供的 CPU 计算能力也几乎相同。注意到，华为云 RDS MySQL 一直是所有云厂商，所提供的计算能力最高的厂商。似乎，是这样，别的云厂商的的 4c16g 通常是，4 个超线程，而华为云似乎真的是提供了 4 个核 (cores)。
百度云 RDS 提供非常稳定的性能。如下图数据所示，四次测试，整体的性能表现非常稳定，地域差异也比较小。
AWS 是所有云厂商中，性能管理做的最好的，对于不同代际的 CPU 在实例代码层面能够直接看到。可以看到，其性能整体上较为稳定，但本次进行两次测试，相比之前要更低一些，从配置和 CPU 计算能力指标来看，并没有明显差别。
Azure 的实例有着很多厂商类似的 CPU 代差导致的性能波动问题，在 202409 的测试中 CPU 计算能力指标为 56.3，相比 202405 表现的 63.9，也下降了 12%，Azure Database for MySQL 的 Sysbench QPS 性能也随之下降。
Google 云的 MySQL 托管服务在最近两年里做了非常多的增强，一方面推出了 AlloyDB，托管 MySQL 也推出了 Enterprise Plus 版本。性能上，202409 的测试中，与 202405 的测试性能并没有太大的差异；此外，它的 Enterprise Plus 版本的性能提升也非常明显，有着更多的 CPU 计算性能，也有着更多的内存资源。
MySQL 是属于 Oracle 的，Oracle 也一直在持续投入发展 MySQL 数据库与社区的建设。Oracle Cloud 是最早推出 MySQL 8.4、MySQL 9.0 的云厂商，这次也一并测试这两个最新版本在 Oracle Cloud 上的表现。
可以看到，整个上各个版本在该测试模型下表现较为一致。仅 8.4.0（也就是 8.4 的第一个版本）在超高并发下，性能有明显退化，而该问题也在最新的 8.4.2 修复了。
该测试很好的展示了不同云厂商之间 RDS MySQL 性能差异，甚至在同一个云厂商的不同区域，甚至在同一个云厂商的同一区域不同时间建立的实例，其性能都可能会有一定的差异。理解了这些，当我们需要在多云之间进行迁移或变更区域时，可以更好地进行数据库的容量规划。
关于作者：orczhou@ninedata，NineData 的联合创始人 & 技术副总裁、Oracle ACE，第三 / 四版译者。
