MySQL数据库上云四年打磨,五大经典案例让你不再“蓝瘦”

  • 时间:
  • 浏览:0



应用场景四:去“O”上云的护航故事

数据库版本地处了变化,最核心的许多但是优化器地处了变化,看图中执行计划中的rows,访问第5个表需用230万行,但是对230万行进行排序,工作量巨大,这但是许多的什么的问题所在。

当性能变快了,要对比数据库资源配置,分析SQL执行计划。





为了更加取舍许多的什么的问题,对比优化器在本地正常的情況下的SQL执行计划,它的rows是非常小的,就是可还可以 能 推断是block_nested_loop优化器的优化,是因为 SQL执行计划的转变,进而是因为 SQL性能下降。

优化SQL



总结排查思路

SQL的执行计划性能较低,走了5个索引的intersect,需用计算小量的数据rows:500137696。第并否有 出理 办法是控制优化器的策略;第二种办法让表走index_finish Time’(‘finish Time)。

总结排查思路

根据经验的沉淀,让让我门可还可以 能 分析确认数据库从云上迁移到云下,MySQL没人更改,就是都不 跨平台迁移和跨版本升级的是因为 。

应用场景三:数据库上云后性能下降紧急救援

最佳实践经验:保持数据库资源配置一致,功能和性能测试缺一不可。

某大型系统从Oracle迁移到RDS MySQL,迁移到RDS后冒出CPU5000%,需用紧急出理 。

3.         数据库的执行计划、优化器、参数配置和硬件配置。

1.         数据库跨平台迁移(PG->MySQL、Oracle->MySQL),淘宝但是都不 小量的Oracle迁到MySQL,也是地处过就是许多的什么的问题。

改写子查询

通过以往的经验分析得出,数据库上云许多的什么的问题是因为 有以下几种情況:

完整篇 总结来看,系统配置要保持一致,包括版本、参数、规格等;还有考虑网络延迟(速度、跨机房等)。

应用场景一:5个参数引发的血案

本文根据阿里云技术专家玄惭于10月14日在2016年杭州云栖大会上的题为“数据库上云经典案例分析”的演讲采集而成。

再看SQL执行计划,对比线下和云上的SQL执行计划,通过观察rows可还可以 能 得出,没人不要 变化,排查到这,似乎是因为 到了山穷水尽的地步。

某手机客户端上云,第一次系统切割失败,数据库CPU 5000%,需用在第二次割接前排除是因为 。

某APP应用上云后数据库CPU5000%,系统回滚会冒出数据丢失;弹性升级需用时间较长,要在白天业务高峰来临之际消除障碍。

数据库CPU5000%是比较容易排查的, 可还可以 能 查询数据库中的SQL为许多慢,发现用户本地的MySQL版本是5.5,云上RDS版本是5.6,用户的每根SQL在本地5.5执行只需用零点几秒,而在RDS上需用十多秒,是因为 所有的应用程序都堆积起来了。

优化器版本

通过将SQL日志一行行看,应用日志一行行的对照,发现但是架构应用和DB觉得一台服务器上,应用和DB没人网络交互,更致命的是,但是的系统架构5个订单要访问数据库500多次,到云上的效应就扩大了,就是性能自然下降了,只能更改代码,优化系统调用。

许多的什么的问题排除——跨版本升级

SQL执行计划

最佳实践经验:保持数据库版本一致,功能和性能测试缺一不可。

4.         云上较明显但是网络延迟(跨可用区域访问、公网延迟、网卡饱满)。



采取第二种办法将idx_delStatus索引删除,索引删除后执行计划恢复正常,性能疾速 提升。rows只需用40行。

是因为 线下环境的SQL低于云上SQL。第一,检查执行计划;第二,检查数据库版本和优化器;第三,对比参数和硬件配置;第四,查看网络延迟。





2.         RDS配置:逻辑CPU8核,内存32G,最大IOPS:15000。

将5个参数一一对比调试,经过测试验证,是tmp_table_size的许多的什么的问题,云上默认是256K,本地是128M,云上实际上是并否有 朴实型的运行环境,参数值是因为 调的很大,许多用户的内存消耗是因为 就会变大,将tmp_table_size调到128M后,性能有所提升,从18秒降低到7秒,基本与本地持平。



这是开发习惯是因为 的许多的什么的问题,gmt_create用字符串存时间, 5.5版本加个索引,它还可以 利用索引,SQL是没人许多的什么的问题的。

测试验证



分析SQL执行计划,对比数据库版本和优化器规则。

某个客户正在将本地系统迁移上云,在RDS上运行时间明显要比线下自建数据库运行时间要慢1倍,是因为 客户系统割接延期的风险。

接下来,对比优化器版本,可还可以 能 看得人用户的数据库版本也没人许多的什么的问题,故而排除优化器许多的什么的问题。

最佳经验实践:子查询在5.1、5.5版本中都地处较大风险,将子查询改为关联,使用MySQL5.6的版本可还可以 能 出理 子查询的许多的什么的问题。

应用场景二:上云版本升级带来性能下降

总结排查思路



2.         跨版本升级(MySQL:5.1->5.5、5.5->5.6),是因为 了性能许多的什么的问题。

接下来检查参数配置,发现用户手工更改了重要的5个参数。

1.         本地物理机配置:2U机箱,2*Intel E5-25009 v2 4核,内存:64G;磁盘ssd,Raid5;

字符串存储时间是因为 隐士转换



应用场景五:网络延迟造成的性能下降



最佳实践经验:需用考虑上云后网络延迟对性能的影响,优化应用与数据库的访问;应用和数据库尽量保持在同5个可用区内访问。

在淘宝去“O”过程中也遇到过类事的许多的什么的问题,排查过程中发现是MySQL的子查询诟病,Oracle开发人员会一个劲 使用但是的SQL做子查询,许多SQL是因为 但是查薪水为50000块人的名字,正常的思维逻辑为先查子查询的结果集,再反带到外面的表去关联,子查询中的结果集是非常小的,循环的次数较少,对性能不需要有不要 影响。但是在MySQL中就不一样了,MySQL只能5个嵌套循环,MySQL的出理 逻辑是遍历employees表中的每每根记录,代入到子查询中去,是因为 employees表不要 ,就会是因为 循环的次数不要 ,使SQL性能受影响。

许多的什么的问题排除

网络延迟放大

参数配置

5.6版本但是,全表扫描2500万数据,就是这条SQL肯定慢,这但是是因为 CPU5000%的根源。



某电商系统迁移上云测试过程中发现性能较低,应用代码、数据库配置完整篇 一样。

对比发现规格配置较小,用户本地物理机的配置是云上RDS的规格两倍,是因为 慢SQL冒出堆积。具体如下: