云数据库 RDS MySQL 的性能综述

在不同的云厂商，购买相同规格的 MySQL 实例，获得的性能相同吗？本文使用 Sysybench，对不同云厂商的同样规格“4vCPU-16GB”进行性能测试来尝试回答上述问题。

全球八大云厂商，云数据库RDS MySQL性能趋势图

Sysbench QPS 详细数据

Query Latency 详细数据

如下表格分别为：平均延迟 和 95%延迟数据。单位为：毫秒/ms。

MySQL 参数对比表格

2024年09月 性能测试趋势图

2024年05月 性能测试趋势图

关于本次测试更多详细说明：云数据库MySQL性能测试@2024年05月。

关于该测试

当在不同的云厂商之间迁移时，数据库的性能是需要重点关注的点。那么，不同的云厂商之间的相同规格实例是不是就可以直接迁移呢？他们之间差异大吗？经过上述的系列测试，我们发现：

• 不同的云厂商之间性能差距非常大
• 即便同一个云厂商，不同的区域之间相同规格性能也有差距
• 即便同一个云厂商，不同时间阶段，相同规格性能也有差距

上述的差异现象，并不是孤立，几乎每个厂商都有类似的问题。有的云厂商性能管理更好，差异会小一些，性能更加稳定，而有的云厂商性能差异则比较大。

如何重现该测试

重现该测试包含了两个方面，一个是测试工具与主要参数，另一个是测试实例的选择。如下两节分别描述这两部分。

Sysbench 参数的参数与命令

该测试选择了模型简单、易于重现的Sysbench（oltp_read_write），其主要参数包括：

• 测试模型：oltp_read_write
• --time=300
• --table_size=10000 --tables=10
• --skip_trx=on --db-ps-mode=disable
• --rand-type=uniform
• 并发线程：4,8,16,32,48,64,96,128,192,256,384,512

测试参考命令：

 sysbench oltp_read_write --threads=$conthread --time=$run_time \
 --report-interval=3 --percentile=95 --histogram=on --db-driver=mysql \
 $sysb_mysql_conn \
 --skip_trx=on --db-ps-mode=disable --rand-type=uniform $ssl_param \
 --table_size=$table_size --tables=$tables run >> $run_file 2>&1

实例规格的选择

这里选取了阿里云、华为云、腾讯云、AWS、Azure、Oracle Cloud、Google Cloud的托管MySQL服务（RDS MySQL）作为测试对象。测试实例实例规格满足如下条件：

• 4vCPU16GB内存规格，存储100GB
• 如果需要选择IOPS，选择3000
• 具备跨可用区的高可用
• 非常高的数据可靠性级别，同步复制或半同步复制，或者MGR复制，或者存储层的同步复制
• 具备非常好的性能一致性（独享的计算资源）

具体每个云厂商的标准规格选择，参考：云数据库RDS MySQL性能测试与对比@2024年05月文中对各个云厂商小结部分。

为什么相同规格性能差异这么大

这是一个比较复杂的问题。该问题作者参加的2024年1月的ACMUG（中国MySQL用户组）大会上的做了分享（参考），如下为分享的PDF，供参考：

概要小结如下：

• 不同云厂商相同的4vCPU规格，其计算能力差异很大
• 不同云厂商 RDS 的高可用架构有一定的差异，这对性能影响也大
• 想通的云厂商，不同阶段上线的实例，使用的CPU代际不同，性能相差明显

关于该测试的限制

本节对在测试过程中的一些限制进行补充说明，供参考：

• 在本系列的的测试中，地域选择较为随机，例如阿里云选择了杭州、百度云选择北京、AWS/谷歌云选择了东京、Azure云选择了美东/香港/东京等。这里的一个假设是，各个云厂商在各个区域的RDS MySQL性能应该是相同或者接近的。
• 首先于个人的时间与资源，这里仅对较为常用的4vCPU16GB的规格进行测试，单次并发测试持续时间为300秒。
• 虽然都是用MySQL 8.0版本，但是不同的厂商的数据库小版本也会不同。
• 不同厂商的CPU、磁盘类型、价格等各有不同，所以这不是一个完全对等的测试，也不可能是。
• 不同厂商的RDS实例的默认参数模板也各有不同，甚至同一个厂商在不同阶段的参数也可能会有调整。
• 有的云厂商的磁盘存储有着多种不同的选择，例如阿里云支持ESSD PL1/2/3，AWS也支持gp3/io1类型的存储选择，不同的存储选择也会对应这个不同的性能。
• 关于可用区的选择：在测试中，尽量会将测试的ECS/EC2/VM等与数据库主节点放在同一个可用区。但依旧有一些情况做不到这一点。例如在这次的测试过程中，GCP在东京地区b可用区，虽然可以创建数据库，但是却没有资源创建VM节点（“A n2-highcpu-8 VM instance is currently unavailable in the asia-northeast1-b zone.”）。

如果有更多建议，可以在本文后留下你的建议，以供后续参考与改进。

其他补充说明

关于Sysbench测试

这里使用常用的、易用重现的Sysbench工具进行测试。主要的模型包括oltp_read_write以及部分自定义模型。Sysbench因为其易用使用，可定制性高被业绩广泛使用，包括AWS、Google Cloud、阿里云、腾讯云等。

sysbench的oltp_read_write模型是一个事务压测模型，单个事务中包含了10个点查、4个范围查询（包括了ORDER BY/SUM/DISTINCT等）、影响索引的更新、不影响索引的更新、删除数据、插入数据。关于该测试模型的详细说明可以参考文章：

• Sysnbench oltp_read_write.lua@GitHub
• Sysbench压测中出现”Duplicate entry”的原因
• Sysbench使用hook以及其性能影响

其他实用结论

先说些一些基于测试的实用结论吧，可以让更多的开发者参考：

1. 不同的云厂商，有着不同的存储架构，不同的安全性/性能考虑，不同的CPU类型/多寡等，看似相同的规格，性能却有着巨大的差异
2. 在阿里云上，强烈建议考虑使用经济版（ARM）替换标准版（x86），很容易获得超30%的性价比（参考）
3. 总是建议使用最新一代CPU实例，通常都可以获得15%的性价比提升，例如AWS m6i vs m5i，m7g vs m6g（参考）
4. 几大云厂商的”企业级”实例的性能有着显著差异，主要原因是主从复制架构、CPU代差、存储架构等不同导致（参考）
5. 国内云厂商都提供了“通用型”实例，以非常小的资源共享换取了非常大的性价比提升，非常适合非关键场景使用（参考）

首次测试

更多相关测试文章