MySQL性能优化之简单sql改写

MySQL性能优化之简单sql改写

1> 

问题描述

某客户集团反馈某模块崩溃,导致系统异常,系统无法登陆;

关闭该模块浏览模块后,系统才恢复正常问题重复出现多次。

 

处理过程

协助排查问题优化过程中发现查询该模块的一个长SQL导致性能问题,其中引发问题的主要原因在下图中的部分SQL片段:

MySQL性能优化之简单sql改写

以上SQL中workflowtye在流程表中存放的为int类型,而子句中的content确为char类型,两个类型不同的字段进行关联比较时,导致索引失效。

修改conten的字段类型为int之后SQL性能恢复正常。

在表设计初期,应将需要进行关联的字段类型设置为同一类型。否则会带来严重的性能问题,后期修改的难度将更大。

 

2> 

问题描述

配合客户上线压测期间,发现某接口查询SQL在数据量比较大时性能无法满足客户要求,需进行改造优化

 

处理过程

该SQL的查询逻辑耗时主要在排序分页上,SQL精简之后的逻辑如下:

 MySQL性能优化之简单sql改写

优化的思路如下:

类似这种分页+排序的SQL,第一种书写的逻辑,在使用createdate和createtime进行排序时,需要通过主键回表查询带出其他附带的字段信息,

虽然可以利用到索引,但是这种逻辑并非最高效的,尤其再分页越靠后的时候,随着偏移量加大,需要拿到内存中的数据就更多,查询耗时就更久。

而第二种SQL的书写方法,requestid和createdate,createtime字段上均有索引,在进行排序和分页时,只需要检索索引即可完成(MySQL的覆盖索引概念),

只获取到分页之后的requestid值再与外部表进行inner join,查询速度会极大的提升,并且查询效率不会因为分页靠后而明显下降。

 

3> 

问题描述

客户环境数据库CPU出现告警信息,协助进行排查数据库相关问题。

 

处理过程

通过慢日志分析对数据库的整体性能分析并进行了优化。

此处列举我们程序中常用的一个问题逻辑:

部分SQL片段如下

 MySQL性能优化之简单sql改写

代码中较多的SQL发现开发人员习惯使用exists逻辑来过滤数据,但是在MySQL中,exists的性能并不是最高的,即使在字段存在索引的情况下,在结结果集比较大情况下,

exists的检索速度远不如inner join的hash连接,而且过多的使用exists容易导致SQL的执行计划异常,而inner join逻辑相对更加直接,简化。

我们推荐的优先逻辑:join  >  exists  >  in

 

posted on 2020-06-09 21:29  数据与人文  阅读(111)  评论(0)  编辑  收藏

上一篇:如何意会微积分(正在更新ing...)


下一篇:SQL中exists, not exists, in, not in的区别