近日，MySQL发布了8.4版本，这是一个新的稳定版。在MySQL版本规划中，在2026年8.0.x生命周期结束后，将成为下一个主流稳定版本。
目前为止，看到该版本并没有特别大的改进。部分改变包括改进了直方图统计信息更新、并行复制、组复制（GR）等，完整的更新可以参考：Changes in MySQL 8.4.0 (2024-04-30, LTS Release)。
Oracle Cloud上也第一时间支持了该版本，于是也通过性能测试的方式，第一时间“尝鲜”了一下该版本。性能测试的趋势图如下：
注意到，在该Sysbench测试模式下：
作为一个稳定版本，期待官方尽快解决。
(more…)本问是一个系列文章的一部分，该系列较为完整的对各个云厂商的RDS MySQL进行了测试，包括了阿里云、腾讯云、华为云、百度云、AWS、Azure、GCP、Oracle Cloud等，更多参考：云数据库RDS MySQL的性能。
在Oracle Cloud Infrastructure（简称OCI，也就是Oracle云）上购买MySQL实例，也会有第三代CPU和第四代CPU规格的选择，分别是：MySQL.VM.Standard.E4.2.32GB和MySQL.VM.Standard.E3.2.32GB。本文对比两个版本规格的价格与性能，以供参考。
E4（AMD EPYC 7J13）、E3（AMD EPYC 7742）同属于AMD系列的CPU，E4似乎主要是在OCI平台，E3较为通用。从性能测试上，可以看到，E4相比于E3有着较为明显的性能优势，以常见的16并发时数据为参考，则E4（MySQL.VM.Standard.E4.2.32GB）相比于E3（MySQL.VM.Standard.E3.2.32GB）性能要高11%。
这也与之前的，“新一代CPU总是有着更高的性能”的结论一致。
(more…)最近，使用sysbench测试时，尝试使用参数--skip_trx=on，很快在实际的测试中就遇到了Duplicate entry的报错，详细的报错如下：
[ 105s ] thds: 64 tps: 845.68 qps: 15226.20 (r/w/o: 11833.15/3393.04/0.00) lat (ms,95%): 82.96 err/s: 0.00 reconn/s: 0.00
[ 108s ] thds: 64 tps: 828.65 qps: 14846.32 (r/w/o: 11547.73/3298.59/0.00) lat (ms,95%): 92.42 err/s: 0.00 reconn/s: 0.00
[ 111s ] thds: 64 tps: 811.67 qps: 14705.36 (r/w/o: 11439.69/3265.67/0.00) lat (ms,95%): 92.42 err/s: 0.00 reconn/s: 0.00
FATAL: mysql_drv_query() returned error 1062 (Duplicate entry '172978' for key 'sbtest4.PRIMARY') for query 'INSERT INTO sbtest4 (id, k, c, pad) V
ALUES (172978, 743044, '85734897298-37760631172-31656179599-77290009462-94351507893-97022333300-02606364258-99231394161-86310536236-00514105136',
'50908340877-51595671823-98046322819-52667567569-56801127593')'
FATAL: `thread_run' function failed: /usr/share/sysbench/oltp_common.lua:488: SQL error, errno = 1062, state = '23000': Duplicate entry '172978' f
or key 'sbtest4.PRIMARY'也注意到，这个错误的出现有一定的偶发性，但是高并发、长时间压测几乎一定会遇到了（在开启了--skip_trx=on参数后）。因为Sysbench没有对”Duplicate entry”该错误进行处理，测试会退出，也就无法正常完成测试。
当多个线程并发时，同时没有使用--skip_trx=on，而是使用MySQL默认的auto commit模式，那么在oltp_read_write模型下则一定的概率（小概率）会出现如下的场景：
| 时间线 | 线程A | 线程B |
| 1 | 生成随机ID X | |
| 2 | 生成随机ID X | |
| 3 | 删除 id 为 X 的记录 delete from sbtest where id = X | |
| 4 | 删除 id 为 X 的记录 delete from sbtest where id = X | |
| 5 | 写入 id 为 X 的记录 insert into sbtest (id…) values ( X …) | |
| 6 | 写入 id 为 X 的记录 insert into sbtest (id…) values ( X …) |
在上面的场景下，最后一步，线程B再次写入id 为 X 的记录时，则会出现冲突。
一般来说，即便发生如上情况，也不会出现Duplicate entry的报错。但，组合一些情况，则会出现。例如，在这里，我们使用了--skip_trx=on，那么线程A的如上行为不是在一个事务中，每个操作是一个独立的事务，那么就会出现Duplicate entry报错。
如果没有使用--skip_trx=on参数，那么在线程2尝试删除记录时，则会遇到锁等待，直到线程1的相关操作全部完成。也就不会出现报错。
在开启了–skip_trx=on之后，如果运行时间足够长，且是多线程并发，则几乎一定会遇到如上错误。可以考虑如下方案避免：
INSERT ... ON DUPLICATE KEY UPDATE（参考）替换原始的INSERT语句一般来说，因为当表的记录数非常多时，遇到该类冲突的概率比较小，做如上处理并不会影响测试的“一致性”。
function sysbench.hooks.sql_error_ignorable(err)
if err.sql_errno == 1062 then -- ER_DUP_ENTRY
-- do nothing
-- con:reconnect()
return true
end
end本问是一个系列文章的一部分，该系列较为完整的对各个云厂商的RDS MySQL进行了测试，包括了阿里云、腾讯云、华为云、百度云、AWS、Azure、GCP、Oracle Cloud等，更多参考：云数据库RDS MySQL的性能。
在MySQL社区的帮助下，终于成功开通了Oracle Cloud，于是，第一时间测试了一下在Oracle Cloud上托管MySQL，看看Oracle MySQL原厂的性能表现如何。
关注我朋友圈的应该知道，在国内自助的注册Oracle Cloud真的非常不容易。所以，特别感谢Oracle MySQL原厂工程师徐轶韬的帮助，他也是《MySQL高可用解决方案-从主从复制到InnoDB Cluster架构》的作者，他的公众号是“MySQL解决方案工程师”，感兴趣可以关注他的公众号。
回到正文，Oracle Cloud的全称是”Oracle Cloud Infrastructure”，也经常被简称为”OCI”。在OCI上提供的MySQL服务，相较于AWS、阿里云来说，产品形态也比较简单。首先，托管MySQL在分类“Databases->MySQL HeatWave->DB Systems”这个类目下，在实例创建过程中，涉及的选项不算多，但是因为名词/定义与其他云厂商有一些不同，所以这里做一些解释。Oracle Cloud上的托管MySQL主要选项为：
在本次测试中，一共进行了三组测试。规格大小统一为：2 OCPU（Oracle CPU）32GB，100GB存储（对应的7500 IOPS），规格代码为MySQL.VM.Standard.E4.2.32GB。三组测试对比项分别为：单节点 vs 三节点和同可用区 vs 跨可用区。三组测试具体为：跨可用区的三节点测试、同可用区的三节点测试、同可用区的单节点测试。详细参数表如下：
整体上，OCI上的MySQL高可用版本（MGR三节点）性能要比单节点低约20%。在三节点的两次测试下，跨可用区与同可用区有着几乎相同的性能表现，从延迟上来看，也非常接近，可用区之间的延迟约为百微秒级别。
相比于其他云厂商，OCI上的MySQL性能表现，并不算高的。从架构层面，Oracle MySQL是唯一一个选择了MGR来实现高可用、跨可用区数据一致性的。
在MySQL的实例创建过程中，会有一些诸如：AD、FD（Fault Domins）等选项。这是OCI特有的关于区域、可用区等选项。关于区域和可用区的概念，Oracle Cloud与其他云厂商虽然都是相同的概念，但是用了完全不同的名称，也是非常容易让人困惑的。
在Oracle中，分了几层概念：Region->Availability Domains->Fault Domains。
OCI上的MySQL使用的MGR来实现高可用、高可靠（参考：High Availability@Oracle Cloud Infrastructure Documentation、Group Replication@MySQL Documentation）。三个不同的MySQL节点分布在三个不同的FD，每个节点使用的存储是OCI上的Block Volume（参考），以iSCSI方式使用，类型是“Higher Performance”（此外，还有Balanced、Ultra High Performance、Lower Cost三种Block Volume）。
根据参数配置来看，Oracle Cloud提供的MySQL三节点是通过MGR实现的，使用的是group_replication_single_primary_mode模式。
mysql> show variables like '%group_replication_single_primary_mode%';
+---------------------------------------+-------+
| Variable_name | Value |
+---------------------------------------+-------+
| group_replication_single_primary_mode | ON |
+---------------------------------------+-------+
1 row in set (0.00 sec)host : 10.0.0.13 sub_dir : 10.0.0.13 ins_code : MySQL.VM.Standard.E4.2.32GB ha_type : ha same_az : 1 region : tokyo storage_size : 100
sysbench for host :10.0.0.13
threads|transactions| queries| time |avg/Latency|95%/Latency
2| 95033| 1900660|300.01| 6.31| 7.56
4| 148751| 2975020|300.01| 8.07| 10.27
8| 214974| 4299480|300.01| 11.16| 13.70
16| 262105| 5242100|300.01| 18.31| 30.81
24| 253583| 5071660|300.03| 28.39| 47.47
32| 272755| 5455100|300.03| 35.20| 54.83
48| 269370| 5387400|300.04| 53.46| 77.19
64| 286891| 5737820|300.06| 66.93| 102.97
96| 276749| 5534980|300.12| 104.08| 161.51
128| 287452| 5749040|300.13| 133.61| 183.21
192| 0| 0| 0.00| 0.00| 0.00
host : 10.0.0.74 sub_dir : 10.0.0.74 ins_code : MySQL.VM.Standard.E4.2.32GB ha_type : ha same_az : region : tokyo storage_size : 100
sysbench for host :10.0.0.74
threads|transactions| queries| time |avg/Latency|95%/Latency
2| 90638| 1812760|300.01| 6.62| 7.84
4| 147270| 2945400|300.01| 8.15| 10.09
8| 215078| 4301560|300.01| 11.16| 13.70
16| 242713| 4854260|300.02| 19.78| 33.72
24| 260072| 5201440|300.02| 27.68| 45.79
32| 273703| 5474060|300.03| 35.07| 56.84
48| 283811| 5676220|300.06| 50.74| 73.13
64| 287176| 5743520|300.06| 66.86| 102.97
96| 283113| 5662260|300.09| 101.74| 158.63
128| 285210| 5704200|300.12| 134.66| 189.93
192| 0| 0| 0.00| 0.00| 0.00
host : 10.0.0.224 sub_dir : 10.0.0.224 ins_code : MySQL.VM.Standard.E4.2.32GB ha_type : standalone same_az : 1 region : tokyo storage_size : 100
sysbench for host :10.0.0.224
threads|transactions| queries| time |avg/Latency|95%/Latency
2| 102033| 2040660|300.00| 5.88| 7.56
4| 186602| 3732040|300.01| 6.43| 8.90
8| 281464| 5629280|300.01| 8.53| 12.30
16| 333418| 6668360|300.02| 14.40| 31.94
24| 345463| 6909260|300.02| 20.84| 47.47
32| 359902| 7198040|300.03| 26.67| 56.84
48| 353246| 7064920|300.06| 40.77| 78.60
64| 370118| 7402360|300.07| 51.88| 99.33
96| 380647| 7612940|300.09| 75.67| 134.90
128| 372683| 7453660|300.12| 103.05| 164.45
192| 0| 0| 0.00| 0.00| 0.00
参考
随着云数据库的普及，数据库的传输加密也会随之被广泛使用。本文，将使用通用测试来看看，开启TLS传输对数据库的性能有什么样的影响。
开启TLS传输加密之后，分别会在建立连接、数据传输两个阶段对性能造成影响。因为建立连接的过程通常是一次性的，连接会被复用，所以这部分的性能开销通常是可以接受的。在传输阶段，是传输加密对性能影响的重要阶段，这时候通常会使用对称加密算法（例如AES256）对数据进行加密，那么实际的对称加密的性能就是对TLS传输加密性能影响最大的部分。需要注意的是，如果应用使用的是短链接（应该尽量避免使用这种方式），TLS加密的密钥交换阶段也会对每个连接建立的过程都有一定的性能影响。
这里选择对RDS MySQL进行测试，云厂商则各自选择国外、国内Top 1的云厂商AWS和阿里云。
使用sysbench 1.1.0版本，测试类型为oltp_read_write，相关参数如下：
本问是一个系列文章的一部分，该系列较为完整的对各个云厂商的RDS MySQL进行了测试，包括了阿里云、腾讯云、华为云、百度云、AWS、Azure、GCP、Oracle Cloud等，更多参考：云数据库RDS MySQL的性能。
这是一个云数据库性能测试系列，旨在通过简单标准的性能测试，帮助开发者、企业了解云数据库的性能，以选择适合的规格与类型。这个系列还包括：
* 阿里云RDS标准版(x86) vs 经济版(ARM)性能对比
* 华为云RDS通用型(x86) vs 鲲鹏(ARM)架构的性能对比
* AWS基于x86 vs Graviton(ARM)的RDS MySQL性能对比（二）
* AWS基于x86 vs Graviton(ARM)的RDS MySQL性能对比
阿里云RDS提供了较为丰富的存储类型选择，包括ESSD PL0、ESSD PL1、ESSD PL2、ESSD PL3、通用云盘、本地SSD。其中ESSD PL0仅在非常小的经济型规格中提供，并不在测试范围内。根据阿里云的官方文档可以看到，从PL0到PL3，性能越来越强，并且IO能力也越来越稳定（详细参考：ESSD云盘@阿里云文档中心），当然价格也越来越贵。这里摘抄了文档中的描述，以及关键的部分，对比如下：
此外，“通用云盘”的说明可以参考阿里云文档描述：“通用云盘兼容ESSD云盘的所有特性，性能与ESSD PL1云盘相同，在ESSD云盘的基础上提供了IO突发能力。” 所以，可以这样理解，通用云盘是一种具备ESSD PL1能力，同时具备更加灵活的IOPS突发增长能力的云盘。突发IOPS部分，将额外计费（有少部分的免费额度），突发IOPS部分的额外费用为：0.02元/万IO。
那么，我们看看在RDS MySQL中这些不同的存储的性能表现。这里依旧选择了“企业级规格”进行比较（企业级规格的定义可以参考：云数据库(RDS MySQL)性能深度测评与对比），详细的性能如下：
可以看到：