MySQL性能优化之简单sql改写

1> 

问题描述

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

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

 

处理过程

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

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

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

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

 

2> 

问题描述

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

 

处理过程

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

 

优化的思路如下：

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

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

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

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

 

3> 

问题描述

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

 

处理过程

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

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

部分SQL片段如下

 

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

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

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