问题SQL优化:从超过300s优化到1s案例分析

网友投稿 590 2023-05-10

问题SQL优化:从超过300s优化到1s案例分析

问题SQL优化:从超过300s优化到1s案例分析

概述

今天发现有个项目应用每次一启动后使用就会导致另外一个应用服务直接崩溃,而这两个应用使用的是同个数据库,经过排查可以发现是报表应用的某个查询功能导致,而咨询开发但却查不出是哪条sql,那就只能靠自己排查了..下面是解决的大致过程。

1、开启慢查询

修改my.ini配置,增加参数

slow-query-log=1  slow_query_log_file="epms-slow.log"  long_query_time=10

修改后重启,观察epms-slow.log日志内容。

2、定位慢sql

发现问题sql如下:

select id, parent, project, name   from zentao.zt_task   where parent = 0   /*and exists (select t.parent from zentao.zt_task t where t.parent > 0)*/   and id in (   select t.parent from zentao.zt_task t where t.parent > 0   );

3、查看执行计划

explain select id, parent, project, name   from zentao.zt_task   where parent = 0   /*and exists (select t.parent from zentao.zt_task t where t.parent > 0)*/   and id in (   select t.parent from zentao.zt_task t where t.parent > 0   );

这里可以看到因为走的全扫,每次都扫5万条,产生笛卡尔积,5万*5万就导致数据库崩溃了。

4、考虑用exists改写sql

explain select id, parent, project, name  from zentao.zt_task t  where parent = 0 and exists (  select a.parent from zentao.zt_task a where a.parent = t.id   )

这里改写后问题还是没解决。

5、考虑with改写

后来发现zt_task表查询了两次,所以考虑with改写来简化,只查一次

WITH tmp AS ( SELECT * FROM zt_task ) SELECT  *   FROM   tmp t1   JOIN tmp t2 ON t1.id = t2.parent

好吧,mysql5.7还不支持with改写,只有到mysql 8版本才支持,所以这里只能放弃这种办法了

6、用子查询join改写

SELECT   distinct t1.parent,   t1.id,   t1.project,   t1.NAME   FROM   zentao.zt_task t1   JOIN ( SELECT t.parent FROM zentao.zt_task t WHERE t.parent > 0 ) ta ON t1.id = ta.parent    AND t1.parent =0

这里要记得去重,改写后查询在1秒内得出结果,满足需求。

总结

通过这道案例一定要记住,多表查询的性能是很差的,当然,性能差是有一个前提的:数据量大。子查询 = 简单查询 + 限定查询 + 多表查询 + 统计查询的综合体;

在之前强调过多表查询不建议大家使用,因为性能很差,但是多表查询最有利的替代者就是子查询,所以子查询(子查询指的就是在一个查询之中嵌套了其他的若干查询)在实际的工作之中使用的相当的多。

版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。

上一篇:Redis进化史:看Redis如何变成缓存
下一篇:Hadoop之父:普通程序员到顶级公司CTO的进阶之路
相关文章