一次数据库上云迁移性能下降的排查

  • 时间:
  • 浏览:0
  • 来源:uu快3诀窍_uu快3app安卓_导航网

1、  数据库跨平台迁移(PG->MySQL、ORALCE->MySQL)

subquery_materialization_cost_based=on,use_index_extensions=on

3.选泽参数配置:

还必须想看 用户调整的那些会话级别的内存参数,还必须帮助每两个查询的中间计算结果尽将会的在内存中完成,避免查询的中间结果落盘导致 性能的下降,但将会那些参数都是会话级别的参数,两个查询就会分配对应大小的内存,则会导致 数据库的内存消耗非常快,将会会导致 数据库出现OOM,当然将会是一点后台执行都是很频繁的查询,通过调整相关的参数,嘴笨 还必须提升SQL的执行性能。在调整了上述参数后,尤其是tmp_table_size与用户配置一致后大次责的SQL性能与用户本地的持平,该参数用于决定结构内存临时表的最大值,每个守护系统进程都是分配(实际起限制作用的是tmp_table_size和max_heap_table_size的最小值),将会内存临时表超出了限制,MySQL就会自动地把它转化为基于磁盘的MyISAM表,优化查询一句话的完后 ,要避免使用临时表,将会嘴笨 避免不了一句话,要保证那些临时表是发生内存中的。将会必须一句话否则你有也不group by一句话,否则你有也不内存,增大tmp_table_size(和max_heap_table_size)的值。

read_buffer_size = 1M

也完后 遇到将会数据库在版本(5.5->5.6)升级后完后 正常执行的SQL变得奇慢务必,导致 整个升级迁移不得不回退,其主也不导致 高版本(5.6)的优化器策略与低版本(5.5)不同,导致 了SQL执行计划发生变化,进也不导致 了sql的性能急剧下降;

某客户目前正在将本地的业务系统迁移上云,测试过程中发现后台运营系统,在rds上运行时间明显要比线下PC上自建数据库运行时间要慢1倍,导致 客户系统割接延期的风险。用户线下一台PC服务器的性能果然还比顶配的RDS跑的快,这让用户对RDS的性能产生了质疑,必须立刻调查导致 。

RDS配置

在优化器以及SQL执行计划上这麼太多的进展后,亲戚大伙儿又刚开始英语 英语 关注用户的数据库参数配置与RDS否是 有差异,将会RDS的一点性能参数是保持官方默认的配置,否是 在这里出了问题图片,也不将用户本地数据库的配置文件拉出来进行了对比,发现了重大线索,用户的参数文件中特意调大也太多再话级别的内存参数,而在RDS那些参数都是默认的配置:

在避免了大次责查询性能后,还发现还有一点SQL的执时间还是发生一点差异,也这麼软件配置上这麼太多的斩获后,亲戚大伙儿的思路想到了否是 硬件配置出现了问题图片。将会数据库的内存配置都是比较大的,亲戚大伙儿自然而然的想到了CPU的配置否是 一致,对比发现用户本地的PC服务器的CPU主频配置比RDS的CPU主频配置高出了20%,同去使用纯CPU计算的SQL在两边的环境进行压测,压测中也发现用户环境SQL的执行时间是RDS的一倍,也不避免措施也不升级主机的CPU主频配置,将会从业务将会数据库层面对SQL进行优化。

多次遇到数据库从Oracle迁移到MySQL后,将会MySQL的优化器在低版本(5.6以下版本)对子查询的优化较差,导致 系统迁移到MySQL后,系统中血块的子查询SQL堆积总爱这麼返回,导致 数据库连接数跑满,数据库的CPU 3000%。

OPTIMIZER_SWITCH:

总结:

tmp_table_size =256K

tmp_table_size = 128M

index_merge=on,index_merge_union=on,index_merge_sort_union=on,

1.选泽优化器版本:

2.选泽SQL执行计划:

semijoin=on,loosescan=on,firstmatch=on,

join_buffer_size = 128M

block_nested_loop=on,batched_key_access=off,materialization=on,

read_rnd_buffer_size = 128M

通常SQL的执行时间在同等数据量的具体情况埋点生变化主要有以下一点场景,其主也不导致 是将会优化器生成的执行计划发生了改变,完后 则会导致 SQL的执行时间发生较大的变化,当然将会调快,都是将会调快,调快是亲戚大伙儿想要想看 的场景:

先确认用户本地的数据库版本和RDS的版本否是 一致的:用户本地的版本5.6.25,RDS的版本5.6.16,也这麼大版本上这麼太多的区别;将会在小版本上有一点差异,必须确认一下优化器中支持的优化类型否是 一致,发现优化类型这麼区别:

4.选泽硬件配置:

用户配置:

join_buffer_size = 1M

2、  跨版本升级(MySQL:5.1->5.5、5.5->5.6)

既然优化器的版本是一致的,也不接下来在确认以下SQL的执行计划否是 一致,将会那些SQL都是后台运行统计分析使用,也不都非常的复杂化,有将会一点表的统计信息不准确,则将会导致 执行计划发生变化。对比用户和RDS两边的SQL执行计划,并这麼发现执行计划发生了怪怪的大的变化,一点小表的执行顺序发生了一点变化,不过这麼太多的影响,将会执行计划的所涉及总rows这麼太多的变化:rows=39900*1*1*140*285*1*1*1*1*1*1*1;

index_condition_pushdown=on,mrr=on,mrr_cost_based=on,

index_merge_intersection=on,engine_condition_pushdown=on,