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

简介:

一、概述

这是我们SQL优化班的一个学员,据说该SQL在生产环境中已经运行了20个小时,快把服务器的磁盘资源耗尽了。这20个小时,我们可爱的学员就是靠着删除一些不重要的文件才能够勉强度过。 
据了解,该SQL为一个月运行一次的跑报表的SQL,主要问题是随着SQL的运行时间越来越长,所需的临时表空间也越来越大,导致磁盘资源用尽。

二、先看慢SQL

 ●  SQL 执行时长 ,目前已经20小时,还在继续执行
 
  1. SELECT

  2. COUNT( * ) AS totalNum,

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

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

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

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

  7. FROM

  8. F

  9. LEFT JOIN DC ON DC.ID = F.CONST_ID

  10. LEFT JOIN V ON V.ID = F.VEHICLE_ID

  11. LEFT JOIN AREA ON AREA.ID = V.SYS_DIVISION_ID

  12. WHERE

  13. DC.ID IS NOT NULL

  14. AND V.ID IS NOT NULL

  15. AND F.DEAL_STATE = 0

  16. AND ALARM_LEVEL IN ( 1, 2, 3 )

  17. AND F.VEHICLE_ID IN (

  18. SELECT

  19. VEHICLE_ID

  20. FROM

  21. GVLK

  22. WHERE

  23. GROUP_ID IN ( SELECT GROUP_ID FROM GULK WHERE USER_ID = 'ff8080816091b09c0161f9b825750a9a' )

  24. UNION

  25. SELECT

  26. VEHICLE_ID

  27. FROM

  28. UVLK

  29. WHERE

  30. USER_ID = 'ff8080816091b09c0161f9b825750a9a'

  31. )

  32. AND date( F.ALARM_TIME ) BETWEEN '2000-01-01'

  33. AND '2018-08-14'

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

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

 ●  查看执行计划 

ca8830e670f25f1c9cbb3a807f6b47326372b67d
该执行计划如何看:
id=1的列开始,可以看出 F表,DC表,V表,AREA表都属于id=1的,原因是他们使用了left join,都属于同一个层级。 
id=2的部分,分成两块,先看靠前的那块, select type 是DEPENDENT SUBQUERY,看table部分是 是一个子查询,注意subquery3,所以具体的子查询是id=3的部分。 靠后的部分是一个简单的SQL。 
id=3的部分,select type是MATERIALIZED ,table 是 UVLK,发生物化视图的是子查询部分中的子查询部分,物化子查询,一般出现物化视图说明子查询中存在嵌套子查询,且是与SQL主体部分完全无关的表,且子查询中并未使用到索引。 
id=4部分,是一个DEPENDENT UNION ,将id=2的DEPENDENT SUBQUERY进行union 
null部分,union result,是将union的结果集,使用了 using tempory。 
id=5部分,是一个子查询,是concat函数的主体部分
问题定位 
 ●   执行计划中可以看出,GVLK, GULK, UVLK 部分均使用了DEPEND SUBQUERY,是性能的瓶颈,DEPEND SUBQUERY是依赖于SQL的主体部分,它的执行次数最大可能和SQL主体部分结果的行数(448612行)一样多,同时,,GVLK, GULK,UVLK几张表的type都为all,并为使用到索引,MySQL中关联未走索引的表,只有nested loop join(将驱动表/外部表的结果集作为循环基础数据,然后循环从该结果集每次一条获取数据作为下一个表的过滤条件查询数据,然后合并结果。),多表 join的结果就是,临时结果集会非常非常的大。
三、SQL优化过程
 ●  验证驱动表F的条件过滤性
 
  
  1. SELECT

  2. COUNT( * ) AS totalNum

  3. FROM

  4. F

  5. WHERE F.DEAL_STATE = 0

  6. AND ALARM_LEVEL IN ( 1, 2, 3 )

  7. AND F.ALARM_TIME BETWEEN '2000-01-01' AND '2018-08-14'

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

 ●  验证子查询的过滤性
 
  
  1. SELECT

  2. VEHICLE_ID

  3. FROM

  4. GVLK

  5. WHERE GROUP_ID IN ( SELECT GROUP_ID FROM GULK WHERE USER_ID = 'ff8080816091b09c0161f9b825750a9a' )

  6. UNION

  7. SELECT

  8. VEHICLE_ID

  9. FROM

  10. UVLK

  11. WHERE USER_ID = 'ff8080816091b09c0161f9b825750a9a'

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

 ●  DEPEND SUBQUERY 改写
 
  
  1. SELECT

  2. COUNT( * ) AS totalNum

  3. FROM

  4. F

  5. join (

  6. SELECT

  7. VEHICLE_ID

  8. FROM

  9. GVLK

  10. WHERE

  11. GROUP_ID IN ( SELECT GROUP_ID FROM GULK WHERE USER_ID = 'ff8080816091b09c0161f9b825750a9a' )

  12. UNION

  13. SELECT

  14. VEHICLE_ID

  15. FROM

  16. UVLK

  17. WHERE

  18. USER_ID = 'ff8080816091b09c0161f9b825750a9a'

  19. ) s

  20. WHERE F.DEAL_STATE = 0

  21. AND ALARM_LEVEL IN ( 1, 2, 3 )

  22. AND F.VEHICLE_ID = s.VEHICLE_ID

  23. AND F.ALARM_TIME BETWEEN '2000-01-01' AND '2018-08-14'

最后运行了如下sql 结果集为 88696 速度为0.5s。采用join的方式替代in的方式,因为 DEPEND SUBQUERY是依赖于SQL的主体部分,执行的次数与被依赖表结果集一致。

四、SQL优化结果

 
  
  1. explain extended

  2. SELECT

  3. COUNT( * ) AS totalNum,

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

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

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

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

  8. FROM

  9. F

  10. straight_join (

  11. SELECT

  12. VEHICLE_ID

  13. FROM

  14. GVLK

  15. WHERE

  16. GROUP_ID IN ( SELECT GROUP_ID FROM GULK WHERE USER_ID = 'ff8080816091b09c0161f9b825750a9a' )

  17. UNION

  18. SELECT

  19. VEHICLE_ID

  20. FROM

  21. UVLK

  22. WHERE

  23. USER_ID = 'ff8080816091b09c0161f9b825750a9a'

  24. ) s on F.VEHICLE_ID = s.VEHICLE_ID

  25. straight_join DC ON DC.ID = F.CONST_ID

  26. straight_join V ON V.ID = F.VEHICLE_ID

  27. straight_join AREA ON AREA.ID = V.SYS_DIVISION_ID

  28. WHERE

  29. DC.ID IS NOT NULL

  30. AND V.ID IS NOT NULL

  31. AND F.DEAL_STATE = 0

  32. AND ALARM_LEVEL IN ( 1, 2, 3 )

  33. AND date( F.ALARM_TIME ) BETWEEN '2000-01-01'

  34. AND '2018-08-14'

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

3777b68c3cdb748f48159f87763ef9e6aaf032ad

优化后的SQL的执行时间几乎是秒出。 
优化的原理已经在优化过程中详细讲解,速度提升上万倍,原因如下:

1、使用join 代替in的方式;

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

四、后记

本文主要在于优化DEPEND SUBQUERY,另外让SQL能够用得上索引,让SQL的速度有着显著的提升。


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

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

本文来自云栖社区合作伙伴“老叶茶馆”,了解相关信息可以关注“老叶茶馆”。

相关文章
|
2月前
|
SQL 存储 关系型数据库
一文搞懂SQL优化——如何高效添加数据
**SQL优化关键点:** 1. **批量插入**提高效率,一次性建议不超过500条。 2. **手动事务**减少开销,多条插入语句用一个事务。 3. **主键顺序插入**避免页分裂,提升性能。 4. **使用`LOAD DATA INFILE`**大批量导入快速。 5. **避免主键乱序**,减少不必要的磁盘操作。 6. **选择合适主键类型**,避免UUID或长主键导致的性能问题。 7. **避免主键修改**,保持索引稳定。 这些技巧能优化数据库操作,提升系统性能。
282 4
一文搞懂SQL优化——如何高效添加数据
|
2月前
|
SQL 存储 数据库连接
日活3kw下,如何应对实际业务场景中SQL过慢的优化挑战?
在面试中,SQL调优是一个常见的问题,通过这个问题可以考察应聘者对于提升SQL性能的理解和掌握程度。通常来说,SQL调优需要按照以下步骤展开。
|
2月前
|
SQL 关系型数据库 MySQL
【MySQL 数据库】7、SQL 优化
【MySQL 数据库】7、SQL 优化
49 0
|
2月前
|
存储 关系型数据库 MySQL
最全MySQL面试60题(含答案):存储引擎+数据库锁+索引+SQL优化等
最全MySQL面试60题(含答案):存储引擎+数据库锁+索引+SQL优化等
194 0
|
4天前
|
SQL 关系型数据库 MySQL
【MySQL】SQL优化
【MySQL】SQL优化
|
8天前
|
SQL 分布式计算 资源调度
一文解析 ODPS SQL 任务优化方法原理
本文重点尝试从ODPS SQL的逻辑执行计划和Logview中的执行计划出发,分析日常数据研发过程中各种优化方法背后的原理,覆盖了部分调优方法的分析,从知道怎么优化,到为什么这样优化,以及还能怎样优化。
103456 0
|
12天前
|
SQL 关系型数据库 MySQL
explain是什么?explain优缺点及如何使用explain优化SQL
explain是什么?explain优缺点及如何使用explain优化SQL
34 1
|
12天前
|
SQL 自然语言处理 数据挖掘
NL2SQL技术方案系列(1):NL2API、NL2SQL技术路径选择;LLM选型与Prompt工程技巧,揭秘项目落地优化之道
NL2SQL技术方案系列(1):NL2API、NL2SQL技术路径选择;LLM选型与Prompt工程技巧,揭秘项目落地优化之道
NL2SQL技术方案系列(1):NL2API、NL2SQL技术路径选择;LLM选型与Prompt工程技巧,揭秘项目落地优化之道
|
15天前
|
SQL 自然语言处理 关系型数据库
NL2SQL进阶系列(3):Data-Copilot、Chat2DB、Vanna Text2SQL优化框架开源应用实践详解[Text2SQL]
NL2SQL进阶系列(3):Data-Copilot、Chat2DB、Vanna Text2SQL优化框架开源应用实践详解[Text2SQL]
NL2SQL进阶系列(3):Data-Copilot、Chat2DB、Vanna Text2SQL优化框架开源应用实践详解[Text2SQL]
|
16天前
|
SQL 关系型数据库 数据库
【后端面经】【数据库与MySQL】SQL优化:如何发现SQL中的问题?
【4月更文挑战第12天】数据库优化涉及硬件升级、操作系统调整、服务器/引擎优化和SQL优化。SQL优化目标是减少磁盘IO和内存/CPU消耗。`EXPLAIN`命令用于检查SQL执行计划,关注`type`、`possible_keys`、`key`、`rows`和`filtered`字段。设计索引时考虑外键、频繁出现在`where`、`order by`和关联查询中的列,以及区分度高的列。大数据表改结构需谨慎,可能需要停机、低峰期变更或新建表。面试中应准备SQL优化案例,如覆盖索引、优化`order by`、`count`和索引提示。优化分页查询时避免大偏移量,可利用上一批的最大ID进行限制。
64 3