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

  • 时间:
  • 浏览:1

tmp_table_size =256K

既然优化器的版本是一致的,全都有接下来在确认以下SQL的执行计划是算不算一致,但是 那先 SQL还会后台运行统计分析使用,全都有都非常的复杂化,有但是 全都表的统计信息不准确,则但是 原应执行计划存在变化。对比用户和RDS两边的SQL执行计划,并那末 发现执行计划存在了一阵一阵大的变化,全都小表的执行顺序存在了全都变化,不过那末 那末来越多的影响,但是 执行计划的所涉及总rows那末 那末来越多的变化:rows=39900*1*1*140*285*1*1*1*1*1*1*1;

subquery_materialization_cost_based=on,use_index_extensions=on

多次遇到数据库从Oracle迁移到MySQL后,但是 MySQL的优化器在低版本(5.6以下版本)对子查询的优化较差,原应系统迁移到MySQL后,系统中大量的子查询SQL堆积时不时 那末 返回,原应数据库连接数跑满,数据库的CPU 80%。

用户配置:

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

index_merge_intersection=on,engine_condition_pushdown=on,

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

4.选取硬件配置:

OPTIMIZER_SWITCH:

先确认用户本地的数据库版本和RDS的版本是算不算不算一致的:用户本地的版本5.6.25,RDS的版本5.6.16,全都有在大版本上那末 那末来越多的区别;但是 在小版本上有全都差异,前要确认一下优化器中支持的优化类型是算不算一致,发现优化类型那末 区别:

3.选取参数配置:

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

1.选取优化器版本:

read_buffer_size = 1M

tmp_table_size = 128M

在除理了大偏离 查询性能后,还发现还有全都SQL的执时间还是存在全都差异,全都有在软件配置上那末 那末来越多的斩获后,让我们的思路想到了是算不算不算硬件配置时不时 出现 了现象图片。但是 数据库的内存配置还会比较大的,让我们自然而然的想到了CPU的配置是算不算不算一致,对比发现用户本地的PC服务器的CPU主频配置比RDS的CPU主频配置高出了20%,共同使用纯CPU计算的SQL在两边的环境进行压测,压测中也发现用户环境SQL的执行时间是RDS的一倍,全都有除理土妙招全都我升级主机的CPU主频配置,但是 从业务但是 数据库层面对SQL进行优化。

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

join_buffer_size = 1M

join_buffer_size = 128M

2.选取SQL执行计划:

read_rnd_buffer_size = 128M

在优化器以及SQL执行计划上那末 那末来越多的进展后,让我们又但是开始关注用户的数据库参数配置与RDS是算不算有差异,但是 RDS的全都性能参数是保持官方默认的配置,是算不算在这里出了现象图片,全都有将用户本地数据库的配置文件拉出来进行了对比,发现了重大线索,用户的参数文件中特意调大全都有会话级别的内存参数,而在RDS那先 参数还会默认的配置:

总结:

RDS配置

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

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

也那我遇到但是 数据库在版本(5.5->5.6)升级后那我正常执行的SQL变得奇慢务必,原应整个升级迁移不得不回退,其主要原应高版本(5.6)的优化器策略与低版本(5.5)不同,原应了SQL执行计划存在变化,进而原应了sql的性能急剧下降;

通常SQL的执行时间在同等数据量的情况汇报整理生变化主要有以下全都场景,其主要原应是但是 优化器生成的执行计划存在了改变,那我则会原应SQL的执行时间存在较大的变化,当但是来 调慢,还会但是 调慢,调慢是让我们不看到到的场景:

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

能无需 看到用户调整的那先 会话级别的内存参数,能无需 帮助每另一个 查询的上面计算结果尽但是 的在内存中完成,除理查询的上面结果落盘原应性能的下降,但但是 那先 参数还会会话级别的参数,另一个 查询就会分配对应大小的内存,则会原应数据库的内存消耗非常快,以还会原应数据库时不时 出现 OOM,当但是来 是全都后台执行还会很频繁的查询,通过调整相关的参数,嘴笨 能无需 提升SQL的执行性能。在调整了上述参数后,尤其是tmp_table_size与用户配置一致后大偏离 的SQL性能与用户本地的持平,该参数用于决定组织组织结构内存临时表的最大值,每个tcp连接池还会分配(实际起限制作用的是tmp_table_size和max_heap_table_size的最小值),但是 内存临时表超出了限制,MySQL就会自动地把它转化为基于磁盘的MyISAM表,优化查询话语的但是 ,要除理使用临时表,但是 嘴笨 除理不了话语,要保证那先 临时表是存在内存中的。但是 前要话语但会 你有全都有group by话语,但会 你有全都有内存,增大tmp_table_size(和max_heap_table_size)的值。