在不同的云厂商购买相同规格的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
“单位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性能最强？》中详细的描述了如下问题：
如何重现该测试：测试工具与参数
该测试中如何选择各个云厂商的4vCPU 16GB的实例：实例规格的选择
关于该测试的限制
本次测试这些内容并没有改变，这里不再赘述。
阿里云 RDS MySQL
本次测试了杭州、北京两个地区RDS MySQL，两个地区的实例性能相差比较明显：4万 vs 3.2万。并且，本次测试性能相比于之前的测试，性能增长明显。从这里的观察来看：
CPU计算能力提升明显
默认情况下关闭了performance_schema
开启或优化了thread_pool ，注意到，thread_pool_size参数发生了变化
腾讯云 TencentDB for MySQL
本次仅测试了腾讯云北京、独享实例，整体的性能表现依旧非常好。纵向的，与5月份的测试对比，性能较为稳定，没有太大的波动。值得注意的是，相比于之前（202405上海区域），本次测试腾讯云的实例使用了更少的“CPU计算能力”，但依旧获得了与之前测试较为接近的性能表现。
华为云 RDS MySQL
本次测试华为云表现稳定，与之前的测试表现非常接近：性能数据接近，版本几乎相同（build号从“8.0.28-231002”升为了“8.0.28-231003”），所提供的CPU计算能力也几乎相同。注意到，华为云RDS MySQL一直是所有云厂商，所提供的计算能力最高的厂商。似乎，是这样，别的云厂商的的4c16g通常是，4个超线程，而华为云似乎真的是提供了4个核(cores)。
百度云 RDS MySQL
百度云RDS提供非常稳定的性能。如下图数据所示，四次测试，整体的性能表现非常稳定，地域差异也比较小。
亚马逊Amazon RDS MySQL
AWS是所有云厂商中，性能管理做的最好的，对于不同代际的CPU在实例代码层面能够直接看到。可以看到，其性能整体上较为稳定，但本次进行两次测试，相比之前要更低一些，从配置和CPU计算能力指标来看，并没有明显差别。
微软Azure Database for MySQL
Azure的实例有着很多厂商类似的CPU代差导致的性能波动问题，在202409的测试中CPU计算能力指标为56.3，相比202405表现的63.9，也下降了12%，Azure Database for MySQL的Sysbench QPS性能也随之下降。
谷歌云上的Cloud SQL Enterprise
Google云的MySQL托管服务在最近两年里做了非常多的增强，一方面推出了AlloyDB，托管MySQL也推出了Enterprise Plus版本。性能上，202409的测试中，与202405的测试性能并没有太大的差异；此外，它的Enterprise Plus版本的性能提升也非常明显，有着更多的CPU计算性能，也有着更多的内存资源。
Oracle Cloud上的HeatWave MySQL
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，<高性能MySQL>第三/四版译者。作者的个人公众号：
