实战演练(二):运行20小时的报表SQL优化后秒出

  • 时间:
  • 浏览:1
  • 来源:uu快3手机版_uu快3走势图_网游

straight_join AREA ON AREA.ID = V.SYS_DIVISION_ID

USER_ID = 'ff5050815091b09c0161f9b825750a9a'

VEHICLE_ID

本文作者:郑松华老师&小鹿

SELECT

 ●  疑问报告 定位

原文发布时间为:2018-10-31

LEFT JOIN AREA ON AREA.ID = V.SYS_DIVISION_ID

AND ALARM_LEVEL IN ( 1, 2, 3 )

SELECT

1、使用join 代替in的依据 ;

COUNT( * ) AS totalNum,

sum( CASE WHEN F.DEAL_STATE = 0 THEN 1 ELSE 0 END ) AS DESTS

id=4帕累托图,是另有2个DEPENDENT UNION ,将id=2的DEPENDENT SUBQUERY进行union

join (

WHERE F.DEAL_STATE = 0

sum( CASE WHEN F.ALARM_LEVEL = 1 THEN 1 ELSE 0 END ) AS LEVELS1,

LEFT JOIN V ON V.ID = F.VEHICLE_ID

UVLK

AND V.ID IS NOT NULL

优化后的SQL的执行时间几乎是秒出。

) s

WHERE

UNION

AND F.VEHICLE_ID IN (

FROM

VEHICLE_ID

AND date( F.ALARM_TIME ) BETWEEN '50-01-01'

 ●  查看执行计划 

SELECT

AND '2018-08-14'

GVLK

FROM

优化的原理可能性在优化过程中完整版讲解,下行数率 提升上万倍,原困如下:

VEHICLE_ID

UVLK

LEFT JOIN DC ON DC.ID = F.CONST_ID

FROM

AND F.DEAL_STATE = 0

COUNT( * ) AS totalNum,

WHERE

最后运行了如下sql 结果集为 88696 下行数率 为0.5s。采用join的依据 替代in的依据 ,可能性 DEPEND SUBQUERY是依赖于SQL的主体帕累托图,执行的次数与被依赖表结果集一致。

UVLK

id=3的帕累托图,select type是MATERIALIZED ,table 是 UVLK,居于物化视图的是子查询帕累托图中的子查询帕累托图,物化子查询,一般经常出现物化视图说明子查询中居于嵌套子查询,且是与SQL主体帕累托图完整版无关的表,且子查询中并未使用到索引。

UVLK

SELECT

SELECT

WHERE

FROM

SELECT

F

VEHICLE_ID

WHERE GROUP_ID IN ( SELECT GROUP_ID FROM GULK WHERE USER_ID = 'ff5050815091b09c0161f9b825750a9a' )

F

上面的sql 运行10s 结果集为393653条数据,说明where 条件中的过滤条件的选用率有的是很好 不适合创建索引。

sum( CASE WHEN F.ALARM_LEVEL = 3 THEN 1 ELSE 0 END ) AS LEVELS3,

sum( CASE WHEN F.ALARM_LEVEL = 3 THEN 1 ELSE 0 END ) AS LEVELS3,

USER_ID = 'ff5050815091b09c0161f9b825750a9a'

id=5帕累托图,是另有2个子查询,是concat函数的主体帕累托图

SELECT

AND '2018-08-14'

AND AREA.PATH LIKE CONCAT( ( SELECT ARE.PATH FROM ARE WHERE ARE.ID = '0' ), '%' )

WHERE

这是亲戚亲戚朋友SQL优化班的另有2个学员,据说该SQL在生产环境中可能性运行了20个小时,快把服务器的磁盘资源耗尽了。这20个小时,亲戚亲戚朋友可爱的学员时候 靠着删除一点不重要的文件才都都还可不都可以 勉下行数率 过。

据了解,该SQL为另有2个月运行一次的跑报表的SQL,主要疑问报告 是随着SQL的运行时间非要长,所需的临时表空间也非要大,原困磁盘资源用尽。

id=1的列刚现在结束了了,还可不都可以 看出 F表,DC表,V表,AREA表都属于id=1的,原困是亲戚亲戚朋友使用了left join,都属于同另有2个层级。

AND date( F.ALARM_TIME ) BETWEEN '50-01-01'

UNION

F

GVLK

sum( CASE WHEN F.ALARM_LEVEL = 2 THEN 1 ELSE 0 END ) AS LEVELS2,

本文主要在于优化DEPEND SUBQUERY,另外让SQL都都还可不都可以 用得上索引,让SQL的下行数率 有着显著的提升。

上面的SQL 运行了0.5s 结果为150条 。in里的结果下行数率 快 结果集很小 ,F表 就该结果进行in操作,也会有大幅度的过滤。

COUNT( * ) AS totalNum

一、概述

DC.ID IS NOT NULL

2、修改后的句子还可不都可以 使用到索引,索引为F.const_id,table为。这里值得一提的是,采用straight_join 代替 了 join,保证了SQL执行顺序一定是按照亲戚亲戚朋友SQL书写的顺序。

四、后记

SELECT

straight_join (

AND V.ID IS NOT NULL

WHERE

UNION

SELECT

SELECT

sum( CASE WHEN F.ALARM_LEVEL = 1 THEN 1 ELSE 0 END ) AS LEVELS1,

DC.ID IS NOT NULL

WHERE

AND ALARM_LEVEL IN ( 1, 2, 3 )

AND ALARM_LEVEL IN ( 1, 2, 3 )

explain extended

GROUP_ID IN ( SELECT GROUP_ID FROM GULK WHERE USER_ID = 'ff5050815091b09c0161f9b825750a9a' )

FROM

SELECT

AND AREA.PATH LIKE CONCAT( ( SELECT ARE.PATH FROM ARE WHERE ARE.ID = '0' ), '%' )

FROM

sum( CASE WHEN F.DEAL_STATE = 0 THEN 1 ELSE 0 END ) AS DESTS

VEHICLE_ID

id=2的帕累托图,分成两块,先看靠前的那块, select type 是DEPENDENT SUBQUERY,看table帕累托图是 是另有2个子查询,注意subquery3,全都 具体的子查询是id=3的帕累托图。 靠后的帕累托图是另有2个简单的SQL。

FROM

该执行计划怎样看:

VEHICLE_ID

AND F.DEAL_STATE = 0

VEHICLE_ID

FROM

) s on F.VEHICLE_ID = s.VEHICLE_ID

COUNT( * ) AS totalNum

GROUP_ID IN ( SELECT GROUP_ID FROM GULK WHERE USER_ID = 'ff5050815091b09c0161f9b825750a9a' )

UNION

AND F.VEHICLE_ID = s.VEHICLE_ID

AND F.ALARM_TIME BETWEEN '50-01-01' AND '2018-08-14'

WHERE

FROM

四、SQL优化结果

null帕累托图,union result,是将union的结果集,使用了 using tempory。

FROM

F

sum( CASE WHEN F.ALARM_LEVEL = 2 THEN 1 ELSE 0 END ) AS LEVELS2,

GVLK

straight_join V ON V.ID = F.VEHICLE_ID

straight_join DC ON DC.ID = F.CONST_ID

WHERE USER_ID = 'ff5050815091b09c0161f9b825750a9a'

FROM

AND F.ALARM_TIME BETWEEN '50-01-01' AND '2018-08-14'

AND ALARM_LEVEL IN ( 1, 2, 3 )

SELECT

三、SQL优化过程

上述SQL的含义:将F左连DC ,V,AREA表的结果进行where过滤,where中居于子查询,一点还有like函数

VEHICLE_ID

GVLK

希望给亲戚亲戚朋友漫漫的SQL优化之旅,带来不一样的火花。

感谢亲戚亲戚朋友细心观看,可能性亲戚亲戚朋友要学习SQL优化,还可不都可以 来「知数堂」跟着SQL优化班授课老师-松华老师,你知道的,不知道的,他都能教你。

USER_ID = 'ff5050815091b09c0161f9b825750a9a'

GROUP_ID IN ( SELECT GROUP_ID FROM GULK WHERE USER_ID = 'ff5050815091b09c0161f9b825750a9a' )

FROM

)

WHERE

执行计划中还可不都可以 看出,GVLK, GULK, UVLK 帕累托图均使用了DEPEND SUBQUERY,是性能的瓶颈,DEPEND SUBQUERY是依赖于SQL的主体帕累托图,它的执行次数最大可能性和SQL主体帕累托图结果的行数(448612行)一样多,一同,,GVLK, GULK,UVLK几张表的type都为all,并为使用到索引,MySQL中关联未走索引的表,非要nested loop join(将驱动表/内部内部结构表的结果集作为循环基础数据,一点循环从该结果集每次一条获取数据作为下另有2个表的过滤条件查询数据,一点合并结果。),多表 join的结果时候 ,临时结果集会非常非常的大。

WHERE F.DEAL_STATE = 0

二、先看慢SQL