对比ECS自建数据库与RDS性能时的注意事项

适用场景

测试ECS自建数据库库与云数据库RDS的性能差异。

背景信息

很多用户都会对比ECS自建数据库与云数据库RDS的性能，但在测试两种数据库的性能时，不仅需要保证二者处于相同的环境下，如相同的网络、配置等，还需要综合考虑数据库的运行机制，否则测试结果会出现偏差且不具有说服力。
云数据库RDS作为一个公共的关系型数据库，高可用和高安全是其首要优势，其次才是高性能，因为没人会使用既不稳定又不安全的服务。RDS的优势主要体现在如下几点：

RDS提供了主备双节点的实例，双节点可以在同一地域的不同可用区，MySQL实例的双节点还可以在不同地域，当主实例出现故障时可快速切换到备实例，保障了RDS的稳定性。
RDS在数据的存取上加入了中间层，所有请求都会经过中间层，而且有SQL注入的请求都会被中间层拦截掉。在底层数据写入上，RDS采用了最高安全级别的写入，保证在主机异常掉电的情况下数据不会出现丢失。以此来保障数据库的高安全性。
RDS源码团队持续对MySQL进行源码优化，在标准的基准测试中性能和稳定性上都是高于社区版本的。

性能测试注意事项

当您进行ECS自建库与云数据库RDS的性能对比时，请注意如下事项。

网络差异

可用区

RDS有单可用区和多可用区之分，单可用区是的数据库主备都在同一个机房，多可用区的数据库主备可能在不同机房，所以在测试RDS的过程中需要保证ECS和RDS在同一个可用区。

网络链路

从ECS到RDS的网络链路中有多个环节，包括了ECS—>DNS—>SLB—>Proxy—>DB（如下图所示），而ECS自建数据库是ECS—>ECS，RDS的网络链路比ECS自建数据库多出了3个链路环节。

案例分析

[backcolor=transparent]场景：某电商要将系统迁移上云，在测试过程中发现，虽然自建库和RDS的应用代码和数据库配置完全相同，但云数据库性能较低。
[backcolor=transparent]原因：网络延迟放大，如下图所示。

配置差异

规格配置

RDS的规格配置主要包括了内存和CPU。在测试RDS的过程中，需要保证ECS的CPU核数与RDS的CPU核数一致。

参数配置

安全配置：RDS为了保证数据的安全性，在参数配置上采用了事务提交和binlog刷写的最高保护级别。
innodb_flush_log_at_trx_commit：该参数指定了InnoDB在事务提交后的日志写入频率。当取值为1时，每次事务提交时log buffer会被写入到日志文件并刷写到磁盘。1是默认值，这是最安全的配置，但由于每次事务都需要进行磁盘I/O，所以有一定的性能损耗。
sync_binlog：该参数是MySQL的binlog日志同步到磁盘的频率。MySQL在binlog每写入sync_binlog次后，刷写到磁盘。该参数值为1时最安全，在每个语句或事务后同步一次binary log，即使在崩溃时也最多丢失一个语句或事务的日志，但因此也最慢。

性能配置：RDS开放了除规格配置以外的参数供用户进行配置，绝大部分的参数都已经由官方团队优化过，用户不需要过多调整线上的参数就可以把数据库比较好的运行起来。但这些参数只是适合大多数的应用场景，针对一些特殊场景，需要您进行特殊定制。

tmp_table_size：该参数用于决定内部内存临时表的最大值，每个线程都要分配（实际起限制作用的是tmp_table_size和max_heap_table_size的最小值），如果内存临时表超出了限制，MySQL就会自动把它转化为基于磁盘的MyISAM表，优化查询语句的时候，要避免使用临时表，如果实在避免不了的话，要保证这些临时表是存在内存中的。
现象：如果复杂的SQL语句中包含了group by/distinct等不能通过索引进行优化而使用了临时表，则会导致SQL执行时间加长。
建议：如果应用中有很多group by/distinct等语句，同时数据库有足够的内存，可以增大tmp_table_size(max_heap_table_size)的值，以此来提升查询性能。
query_cache_size：该参数用于控制MySQL query cache的内存大小。如果MySQL开启query cache，在执行每一个query的时候会先锁住query cache，然后判断是否存在query cache中，如果存在直接返回结果，如果不存在，则再进行引擎查询等操作。同时，insert、update和delete这样的操作都会将query cahce失效掉，这种失效还包括结构或者索引的任何变化，cache失效的维护代价较高，会给MySQL带来较大的压力。所以，当我们的数据库不是特别频繁更新时，query cache是比较好用的；但如果写入非常频繁，并集中在某几张表上的时候，query cache lock的锁机制会造成很频繁的锁冲突，对于这一张表的写和读会互相等待query cache lock解锁，导致select的查询效率下降。
现象：数据库中有大量的连接状态为checking query cache for query、Waiting for query cache lock、storing result in query cache。
建议：RDS默认关闭query cache功能，如果您的实例打开了query cache，当出现上述情况后可以关闭query cache。当然有些情况也可以打开query cache，以解决数据库性能问题。

案例分析

[backcolor=transparent]场景：某客户正在将本地的业务系统迁移上云，在RDS上运行时间明显要比线下自建数据库运行时间要慢1倍。
[backcolor=transparent]原因：自建数据库与RDS的参数配置不同，如下所示：

用户本地参数配置：
join_buffer_size = 128M
read_rnd_buffer_size = 128M
tmp_table_size = 128M
RDS参数配置：
join_buffer_size = 1M
read_buffer_size = 1M
tmp_table_size =256K

架构差异

RDS采用了主从复制的高可用模式，同时打开了半同步复制，半同步复制是MySQL异步复制的改进，当主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待从库接收到并写到relay log中才返回给客户端。相对于异步复制，半同步复制提高了数据的安全性，同时它也造成了一定程度的延迟，这个延迟最少是一个TCP/IP往返的时间。所以半同步复制增加了事务的响应时间，详情如下图所示。