性能测试：自建数据库对比RDS中应当注意的地方
常常很多用户对比测试自建数据库和RDS的性能差异，其测试结果往往是RDS不如ECS自建，用户往往怀疑难道我花了那么多的钱买的RDS难道还不如自己在ECS上搭建？
从数据库测试的角度来看，测试首先必须是的公平的进行，其结果才具有说服力。RDS作为一个公共的关系数据库服务，其必须要包括稳定高可用，高安全，然后才是高性能。没有前面的两者，我相信没有多少人愿意去使用即不稳定又不安全的服务。所以RDS在稳定性上必须上主备双节点的，双节点甚至是在不同机房，万一其中一个机房异常还可以快速切换到另外一个机房。其次RDS必须要保证数据的安全，如果你写入提交的一条数据突然不见了，如果突然有一天你的数据库被黑客SQL注入了，你还愿意继续使用RDS吗。作为服务厂商RDS必须为用户考虑数据安全，在数据的存取上RDS加入了中间层，所有的请求经过中间层后如果有SQL注入的请求都会被中间层拦截掉；在底层数据写入上RDS采用了最高安全级别的写入，保证在主机异常掉电的情况下数据不会出现丢失。最后在性能上，RDS源码团队持续对MySQL源码优化，在标准的基准测试中性能和稳定性上都是高于社区版本的。
下面我们来总结一下RDS和自建数据库在性能测试中需要注意的地方：
一.网络差异
1.可用区
RDS有单可用区和多可用区之分，单可用区是的数据库主备都在同一个机房，多可用区的数据库主备在不同机房，所以在测试RDS的过程中需要保证ECS和RDS是在同一个可用区的。
2.网络链路
从ECS到RDS的网络链路中有多个环节，包括了ECS-->DNS-->SLB-->Proxy-->DB，所以对比ECS自建数据库（ECS-->ECS），RDS的网络链路比ECS自建数据库多出了3个链路环节。
3.案例分析
•1、
某电商系统迁移上云测试过程中发现性能较低
•2、
应用代码，数据库配置完全一样
RDS访问链路：
二.配置差异
1.规格配置
RDS的规格配置主要包括了内存和CPU，在测试RDS的过程中，需要保证ECS的CPU核数和RDS的CPU核数保持一致
2.参数配置
(1).安全配置：RDS的为了保证数据的安全性，在参数配置上采用了事务提交和binlog刷写的最高保护级别。
a.innodb_flush_log_at_trx_commit 参数指定了 InnoDB 在事务提交后的日志写入频率，当取值为 1 时，每次事务提交时，log buffer 会被写入到日志文件并刷写到磁盘。这也是默认值。这是最安全的配置，但由于每次事务都需要进行磁盘I/O，所以有一定的性能损耗。
b.sync_binlog 是 MySQL 的binlog日志同步到磁盘的频率。MySQL在binlog每写入sync_binlog
次后，刷写到磁盘，设为 1 最安全，在每个语句或事务后同步一次 binary log，即使在崩溃时也最多丢失一个语句或事务的日志，但因此也最慢。
(2).性能配置：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，比如：巧用query cache解决数据库性能问题。
3.案例分析
•1、 某客户正在将本地的业务系统迁移上云
•2、 在rds上运行时间明显要比线下自建数据库运行时间要慢1倍
用户本地参数配置：
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
三.架构差异
1.主从复制
RDS采用了主从复制的高可用模式，同时打开了半同步复制，半同步复制是MySQL异步复制的改进，当主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待从库接收到并写到relay log中才返回给客户端。相对于异步复制，半同步复制提高了数据的安全性，同时它也造成了一定程度的延迟，这个延迟最少是一个TCP/IP往返的时间。所以半同步复制增加了事务的响应时间。
备注：SQLSERVER高可用采用mirror，同样存在上述的问题。