通过以往的经验分析得出，数据库上云问题可能有以下几种情况：
1.
数据库跨平台迁移（pg->mysql、oracle->mysql），淘宝以前就有大量的oracle迁到mysql，也是发生过很多问题。
2.
跨版本升级（mysql：5.1->5.5、5.5->5.6），导致了性能问题。
3.
数据库的执行计划、优化器、参数配置和硬件配置。
4.
云上较明显就是网络延迟（跨可用区域访问、公网延迟、网卡饱满）。
应用场景一：一个参数引发的血案
某个客户正在将本地系统迁移上云，在rds上运行时间明显要比线下自建数据库运行时间要慢1倍，导致客户系统割接延期的风险。
根据经验的沉淀，我们可以分析确认数据库从云上迁移到云下，mysql没有更改，所以不是跨平台迁移和跨版本升级的原因。
<b>优化器版本</b><b></b>
接下来，对比优化器版本，可以看到用户的数据库版本也没有问题，故而排除优化器问题。
<b>sql</b><b>执行计划</b><b></b>
再看sql执行计划，对比线下和云上的sql执行计划，通过观察rows可以得出，没有太大变化，排查到这，似乎已经到了山穷水尽的地步。
<b>参数配置</b><b></b>
接下来检查参数配置，发现用户手工更改了重要的三个参数。
<b>测试验证</b><b></b>
将三个参数一一对比调试，经过测试验证，是tmp_table_size的问题，云上默认是256k，本地是128m，云上实际上是一种朴实型的运行环境，参数值如果调的很大，其他用户的内存消耗可能就会变大，将tmp_table_size调到128m后，性能有所提升，从18秒降低到7秒，基本与本地持平。
<b>总结排查思路</b><b></b>
如果线下环境的sql低于云上sql。第一，检查执行计划；第二，检查数据库版本和优化器；第三，对比参数和硬件配置；第四，查看网络延迟。
应用场景二：上云版本升级带来性能下降
某手机客户端上云，第一次系统切割失败，数据库cpu 100%，需要在第二次割接前排除原因。
<b>问题排除——跨版本升级</b><b></b>
数据库cpu100%是比较容易排查的， 可以查询数据库中的sql为什么慢，发现用户本地的mysql版本是5.5，云上rds版本是5.6，用户的一条sql在本地5.5执行只需要零点几秒，而在rds上需要十多秒，导致所有的线程都堆积起来了。
数据库版本发生了变化，最核心的一点就是优化器发生了变化，看图中执行计划中的rows，访问第一个表需要25万行，并且对25万行进行排序，工作量巨大，这就是问题所在。
为了更加确定问题，对比优化器在本地正常的情况下的sql执行计划，它的rows是非常小的，所以可以推断是block_nested_loop优化器的优化，导致sql执行计划的转变，进而导致sql性能下降。
<b>字符串存储时间导致隐士转换</b><b></b>
这是开发习惯导致的问题，gmt_create用字符串存时间， 5.5版本加个索引，它能够利用索引，sql是没有问题的。
5.6版本之后，全表扫描280万数据，所以这条sql肯定慢，这就是导致cpu100%的根源。
分析sql执行计划，对比数据库版本和优化器规则。
最佳实践经验：保持数据库版本一致，功能和性能测试缺一不可。
应用场景三：数据库上云后性能下降紧急救援
某app应用上云后数据库cpu100%，系统回滚会出现数据丢失；弹性升级需要时间较长，要在白天业务高峰来临之际消除障碍。
<b>问题排除</b><b></b>
对比发现规格配置较小，用户本地物理机的配置是云上rds的规格两倍，导致慢sql出现堆积。具体如下：
本地物理机配置：2u机箱，2*intel e5-2609 v2 4核，内存：64g；磁盘ssd，raid5；
rds配置：逻辑cpu8核，内存32g，最大iops：12000。
<b>优化</b><b>sql</b>
sql的执行计划性能较低，走了两个索引的intersect，需要计算大量的数据rows：30137696。第一种解决办法是控制优化器的策略；第二种办法让表走index_finish time’(‘finish time)。
采取第二种办法将idx_delstatus索引删除，索引删除后执行计划恢复正常，性能急速提升。rows只需要40行。
当性能变慢了，要对比数据库资源配置，分析sql执行计划。
最佳实践经验：保持数据库资源配置一致，功能和性能测试缺一不可。
应用场景四：去“o”上云的护航故事
某大型系统从oracle迁移到rds mysql，迁移到rds后出现cpu100%，需要紧急解决。
<b>改写子查询</b><b></b>
在淘宝去“o”过程中也遇到过类似的问题，排查过程中发现是mysql的子查询诟病，oracle开发人员会经常使用这样的sql做子查询，这个sql可能就是查薪水为5000块人的名字，正常的思维逻辑为先查子查询的结果集，再反带到外面的表去关联，子查询中的结果集是非常小的，循环的次数较少，对性能不会有太大影响。但是在mysql中就不一样了，mysql只有一个嵌套循环，mysql的处理逻辑是遍历employees表中的每一条记录，代入到子查询中去，如果employees表太大，就会导致循环的次数太多，使sql性能受影响。
最佳经验实践：子查询在5.1、5.5版本中都存在较大风险，将子查询改为关联，使用mysql5.6的版本可以避免子查询的问题。
应用场景五：网络延迟造成的性能下降
某电商系统迁移上云测试过程中发现性能较低，应用代码、数据库配置完全一样。
<b>网络延迟放大</b><b></b>
通过将sql日志一行行看，应用日志一行行的对照，发现原来架构应用和db实在一台服务器上，应用和db没有网络交互，更致命的是，原来的系统架构一个订单要访问数据库200多次，到云上的效应就扩大了，所以性能自然下降了，只能更改代码，优化系统调用。
最佳实践经验：需要考虑上云后网络延迟对性能的影响，优化应用与数据库的访问；应用和数据库尽量保持在同一个可用区内访问。
全部总结来看，系统配置要保持一致，包括版本、参数、规格等；还有考虑网络延迟（带宽、跨机房等）。
本文根据阿里云技术专家玄惭于10月14日在2016年杭州云栖大会上的题为“数据库上云经典案例分析”的演讲整理而成。