记一次SQL性能优化,查询时间从4000ms优化到200ms.
以下这句SQL是从PLM中获取代办工作流的。没优化前SQL语句执行一次大概4000ms（4秒）。
select ch.change_number changeNumber, f.text changeDetail, u1.last_name creator,
l.value status, to_char(create_date,'yyyy-mm-dd hh24:mi:ss') createDate,
so.signoff_status type
from agile.change ch
inner join agile.workflow_process wp on (ch.id=wp.change_id and ch.status=wp.state and wp.changed_by is null)
inner join agile.signoff so on wp.id=so.process_id and so.signoff_status in (0,4) and so.required in(1,5)
inner join agile.agileuser u on u.id=so.user_assigned
inner join agile.langtable l on (ch.status=l.id and l.type=4450 and l.langid=4)
inner join agile.agileuser u1 on ch.originator=u1.id
left join agile.agile_flex f on f.id=ch.id and f.attid=2017
where (ch.subclass in (2473549,2473495,1,2475794,2473579,2474897,2473519,2480885,2479577,2473531,2485198,2479783)
or (ch.subclass = 2478248 and l.value = '审批'))
and u.email ='zhangsan@kedacom.com'
使用autotrace分析sql
set autotrace on
set timing on
分析结果如下：
Elapsed: 00:00:00.008
Plan hash value: 1883359798 ------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 24 | 5280 | 954 (1)| 00:00:12 |
| 1 | NESTED LOOPS OUTER | | 24 | 5280 | 954 (1)| 00:00:12 |
| 2 | NESTED LOOPS | | 22 | 3564 | 921 (1)| 00:00:12 |
| 3 | NESTED LOOPS | | 22 | 3234 | 910 (1)| 00:00:11 |
| 4 | NESTED LOOPS | | 56 | 6328 | 882 (1)| 00:00:11 |
| 5 | NESTED LOOPS | | 156 | 11076 | 804 (1)| 00:00:10 |
| 6 | NESTED LOOPS | | 212 | 10176 | 592 (1)| 00:00:08 |
|* 7 | TABLE ACCESS FULL | AGILEUSER | 1 | 29 | 168 (1)| 00:00:03 |
|* 8 | TABLE ACCESS BY INDEX ROWID| SIGNOFF | 210 | 3990 | 424 (0)| 00:00:06 |
|* 9 | INDEX RANGE SCAN | SIGNOFF_IDX4 | 1120 | | 3 (0)| 00:00:01 |
|* 10 | TABLE ACCESS BY INDEX ROWID | WORKFLOW_PROCESS | 1 | 23 | 1 (0)| 00:00:01 |
|* 11 | INDEX UNIQUE SCAN | WF_PROCESS_PK | 1 | | 1 (0)| 00:00:01 |
|* 12 | TABLE ACCESS BY INDEX ROWID | CHANGE | 1 | 42 | 1 (0)| 00:00:01 |
|* 13 | INDEX UNIQUE SCAN | CHANGE_PK | 1 | | 1 (0)| 00:00:01 |
|* 14 | TABLE ACCESS BY INDEX ROWID | LANGTABLE | 1 | 34 | 1 (0)| 00:00:01 |
|* 15 | INDEX UNIQUE SCAN | LANGTABLE_PK | 1 | | 1 (0)| 00:00:01 |
| 16 | TABLE ACCESS BY INDEX ROWID | AGILEUSER | 1 | 15 | 1 (0)| 00:00:01 |
|* 17 | INDEX UNIQUE SCAN | AGILEUSER_PK | 1 | | 1 (0)| 00:00:01 |
| 18 | TABLE ACCESS BY INDEX ROWID | AGILE_FLEX | 1 | 58 | 2 (0)| 00:00:01 |
|* 19 | INDEX RANGE SCAN | AGILE_FLEX_UQ | 1 | | 1 (0)| 00:00:01 |
------------------------------------------------------------------------------------------------------ Predicate Information (identified by operation id):
--------------------------------------------------- 7 - filter("U"."EMAIL"='fanjiangen@kedacom.com')
8 - filter(("SO"."REQUIRED"=1 OR "SO"."REQUIRED"=5) AND ("SO"."SIGNOFF_STATUS"=0 OR
"SO"."SIGNOFF_STATUS"=4))
9 - access("U"."ID"="SO"."USER_ASSIGNED")
10 - filter("WP"."CHANGED_BY" IS NULL)
11 - access("WP"."ID"="SO"."PROCESS_ID")
12 - filter(("CH"."SUBCLASS"=1 OR "CH"."SUBCLASS"=2473495 OR "CH"."SUBCLASS"=2473519 OR
"CH"."SUBCLASS"=2473531 OR "CH"."SUBCLASS"=2473549 OR "CH"."SUBCLASS"=2473579 OR
"CH"."SUBCLASS"=2474897 OR "CH"."SUBCLASS"=2475794 OR "CH"."SUBCLASS"=2478248 OR
"CH"."SUBCLASS"=2479577 OR "CH"."SUBCLASS"=2479783 OR "CH"."SUBCLASS"=2480885 OR
"CH"."SUBCLASS"=2485198) AND "CH"."STATUS"="WP"."STATE")
13 - access("CH"."ID"="WP"."CHANGE_ID")
14 - filter("CH"."SUBCLASS"=1 OR "CH"."SUBCLASS"=2473495 OR "CH"."SUBCLASS"=2473519 OR
"CH"."SUBCLASS"=2473531 OR "CH"."SUBCLASS"=2473549 OR "CH"."SUBCLASS"=2473579 OR
"CH"."SUBCLASS"=2474897 OR "CH"."SUBCLASS"=2475794 OR "CH"."SUBCLASS"=2479577 OR
"CH"."SUBCLASS"=2479783 OR "CH"."SUBCLASS"=2480885 OR "CH"."SUBCLASS"=2485198 OR
"CH"."SUBCLASS"=2478248 AND "L"."VALUE"='审批')
15 - access("L"."LANGID"=4 AND "L"."TYPE"=4450 AND "CH"."STATUS"="L"."ID")
17 - access("CH"."ORIGINATOR"="U1"."ID")
19 - access("F"."ID"(+)="CH"."ID" AND "F"."ATTID"(+)=2017)
filter("F"."ATTID"(+)=2017) Statistics
-----------------------------------------------------------
1 DB time
1 Requests to/from client
2 non-idle wait count
1 opened cursors cumulative
1 opened cursors current
1 pinned cursors current
58008 session uga memory
2 user calls
从解释计划中可以看出有2个地方预估时间很长，一个是对agileuser用户表，另一个是signoff，用户审批表。
用户表总共也就几千条记录，而且邮箱还是唯一的，所以资源耗费不是很大。而signoff表数据基数相当庞大，达到百万级。
虽然已经走了索引了，但是走的索引是审批用户的ID这个字段。对于绝大部分人来说，其下的数据不是很多。所以查询起来不会很慢。
但对于某些重要领导（大部分审批流都要他批的那种）数据量就会变得相当庞大。而这个SQL执行慢也恰好是遇到了这样的领导才会慢。
经过具体问题，根据某领导张三的用户ID可以在这张表中查询到2万多数据。也就是说数据库引擎根据现有索引找到该用户的记录后，还要从2万多记录中找到当前需要审批的记录。
分析至此，考虑将用户id以及sql语句中另外的2个条件加入组合索引。重新使用autotrace分析语句，结果如下：
Elapsed: 00:00:00.008
Plan hash value: 441713506 -------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 24 | 5280 | 622 (1)| 00:00:08 |
| 1 | NESTED LOOPS OUTER | | 24 | 5280 | 622 (1)| 00:00:08 |
| 2 | NESTED LOOPS | | 22 | 3564 | 589 (1)| 00:00:08 |
| 3 | NESTED LOOPS | | 22 | 3234 | 578 (1)| 00:00:07 |
| 4 | NESTED LOOPS | | 56 | 6328 | 550 (1)| 00:00:07 |
| 5 | NESTED LOOPS | | 156 | 11076 | 472 (1)| 00:00:06 |
| 6 | NESTED LOOPS | | 212 | 10176 | 260 (1)| 00:00:04 |
|* 7 | TABLE ACCESS FULL | AGILEUSER | 1 | 29 | 168 (1)| 00:00:03 |
| 8 | INLIST ITERATOR | | | | | |
| 9 | TABLE ACCESS BY INDEX ROWID| SIGNOFF | 210 | 3990 | 93 (2)| 00:00:02 |
|* 10 | INDEX RANGE SCAN | SIGNOFF_IDX_KD_1 | 210 | | 3 (34)| 00:00:01 |
|* 11 | TABLE ACCESS BY INDEX ROWID | WORKFLOW_PROCESS | 1 | 23 | 1 (0)| 00:00:01 |
|* 12 | INDEX UNIQUE SCAN | WF_PROCESS_PK | 1 | | 1 (0)| 00:00:01 |
|* 13 | TABLE ACCESS BY INDEX ROWID | CHANGE | 1 | 42 | 1 (0)| 00:00:01 |
|* 14 | INDEX UNIQUE SCAN | CHANGE_PK | 1 | | 1 (0)| 00:00:01 |
|* 15 | TABLE ACCESS BY INDEX ROWID | LANGTABLE | 1 | 34 | 1 (0)| 00:00:01 |
|* 16 | INDEX UNIQUE SCAN | LANGTABLE_PK | 1 | | 1 (0)| 00:00:01 |
| 17 | TABLE ACCESS BY INDEX ROWID | AGILEUSER | 1 | 15 | 1 (0)| 00:00:01 |
|* 18 | INDEX UNIQUE SCAN | AGILEUSER_PK | 1 | | 1 (0)| 00:00:01 |
| 19 | TABLE ACCESS BY INDEX ROWID | AGILE_FLEX | 1 | 58 | 2 (0)| 00:00:01 |
|* 20 | INDEX RANGE SCAN | AGILE_FLEX_UQ | 1 | | 1 (0)| 00:00:01 |
------------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id):
--------------------------------------------------- 7 - filter("U"."EMAIL"='fanjiangen@kedacom.com')
10 - access("U"."ID"="SO"."USER_ASSIGNED" AND ("SO"."SIGNOFF_STATUS"=0 OR
"SO"."SIGNOFF_STATUS"=4) AND ("SO"."REQUIRED"=1 OR "SO"."REQUIRED"=5))
11 - filter("WP"."CHANGED_BY" IS NULL)
12 - access("WP"."ID"="SO"."PROCESS_ID")
13 - filter(("CH"."SUBCLASS"=1 OR "CH"."SUBCLASS"=2473495 OR "CH"."SUBCLASS"=2473519 OR
"CH"."SUBCLASS"=2473531 OR "CH"."SUBCLASS"=2473549 OR "CH"."SUBCLASS"=2473579 OR
"CH"."SUBCLASS"=2474897 OR "CH"."SUBCLASS"=2475794 OR "CH"."SUBCLASS"=2478248 OR
"CH"."SUBCLASS"=2479577 OR "CH"."SUBCLASS"=2479783 OR "CH"."SUBCLASS"=2480885 OR
"CH"."SUBCLASS"=2485198) AND "CH"."STATUS"="WP"."STATE")
14 - access("CH"."ID"="WP"."CHANGE_ID")
15 - filter("CH"."SUBCLASS"=1 OR "CH"."SUBCLASS"=2473495 OR "CH"."SUBCLASS"=2473519 OR
"CH"."SUBCLASS"=2473531 OR "CH"."SUBCLASS"=2473549 OR "CH"."SUBCLASS"=2473579 OR
"CH"."SUBCLASS"=2474897 OR "CH"."SUBCLASS"=2475794 OR "CH"."SUBCLASS"=2479577 OR
"CH"."SUBCLASS"=2479783 OR "CH"."SUBCLASS"=2480885 OR "CH"."SUBCLASS"=2485198 OR
"CH"."SUBCLASS"=2478248 AND "L"."VALUE"='审批')
16 - access("L"."LANGID"=4 AND "L"."TYPE"=4450 AND "CH"."STATUS"="L"."ID")
18 - access("CH"."ORIGINATOR"="U1"."ID")
20 - access("F"."ID"(+)="CH"."ID" AND "F"."ATTID"(+)=2017)
filter("F"."ATTID"(+)=2017) Statistics
-----------------------------------------------------------
1 CPU used by this session
1 Requests to/from client
2 non-idle wait count
1 opened cursors cumulative
1 opened cursors current
1 pinned cursors current
2 user calls
>>Query Run In:查询结果 3
从上面的结果可以看出，sql走入了新建的组合索引（SIGNOFF_IDX_KD_1），预估执行时间从原来的06秒变成02秒，cost也大幅度下降，整句SQL的执行时间也从4秒多下降到了200ms。
由此可见，索引对于查询的优化真是显而易见。
记一次SQL性能优化,查询时间从4000ms优化到200ms.的更多相关文章
- sql exist 优化查询时间
1.非exist,查询需要20多秒 2.使用exist后 3.表连接也能优化
- PHP获取MySQL执行sql语句的查询时间
//计时开始 runtime(); //执行查询 mysql_query($sql); //计时结束. echo runtime(1); //计时函数 function runtime($mode=0 ...
- sql server获取查询时间
declare @d datetime set @d=getdate() /*你的SQL脚本开始*/ /*你的SQL脚本结束*/ select [语句执行花费时间(毫秒)]=datediff(ms,@ ...
- 计算sql语句的查询时间
set statistics profile on set statistics io on set statistics time on go <这里写上你的语句...> go set ...
- （转载）PHP怎么获取MySQL执行sql语句的查询时间
(转载自CSDN) 方法一: //计时开始 runtime(); //执行查询 mysql_query($sql); //计时结束. echo runtime(1); //计时函数 function ...
- 记一次sql server 性能调优，查询从20秒至2秒
一.需求 需求很简单,就是需要查询一个报表,只有1个表,数据量大约60万左右,但是中间有些逻辑. 先说明一下服务器配置情况:1核CPU.2GB内存.机械硬盘.Sqlserver 2008 R2.Win ...
- SQL性能优化-查询条件与字段分开执行，union代替in与or，存储过程代替union
PS:概要.背景.结语都是日常“装X”,可以跳过直接看优化历程 环境:SQL Server 2008 R2.阿里云RDS:辅助工具:SQL 审计 概要 一个订单列表分页查询功能,单从SQL性能来讲,从 ...
- SQL Server 2016 查询存储性能优化小结
SQL Server 2016已经发布了有半年多,相信还有很多小伙伴还没有开始使用,今天我们来谈谈SQL Server 2016 查询存储性能优化,希望大家能够喜欢 作为一个DBA,排除SQL Ser ...
- 性能优化-查询最耗CPU的SESSION与SQL
在linux 系统中 用top命令查出CPU最高的SPID,再将SPID给存储过程,可以查出该进程的SQLTEXT create or replace procedure pro_get_sqltex ...
随机推荐
- python 保存对象文件
之前用 R 语言一直感觉 .Rdata 格式的文件很好用,可以把每次执行的中间文件保存便于下次调用,刚熟悉 Python 还没接触这块知识,所以有时候做项目不太顺手,索性上网搜了下,整理如下: 模型存 ...
- python 连接 oracle 统计指定表格所有字段的缺失值数
python连接oracle -- qlalchemy import cx_Oracle as co import pandas as pd from sqlalchemy import crea ...
- 算法笔记 3.2 codeup1935 查找学生信息
#include <stdio.h> #include <string.h> const int maxn = 1e3; struct student{ ]; ]; //!!! ...
- istream不是std的成员
如果报错信息为:istream不是std的成员,那么有两种可能 1.没有包含iostream库文件 2.#ifndef 和#endif使用错误,致使包含的iostream的头文件没有被主函数包含
- Hbase 与Hive整合
HBase与Hive的对比 25.1.Hive 25.1.1.数据仓库 Hive的本质其实就相当于将HDFS中已经存储的文件在Mysql中做了一个双射关系,以方便使用HQL去管理查询. 25.1.2. ...
- [转]阿里巴巴十年Java架构师分享，会了这个知识点的人都去BAT了
1.源码分析专题 详细介绍源码中所用到的经典设计思想,看看大牛是如何写代码的,提升技术审美.提高核心竞争力. 帮助大家寻找分析源码的切入点,在思想上来一次巨大的升华.知其然,并知其所以然.把知识变成自 ...
- DotNetBar中Supergrid显示树形数据
1.向窗体中拖一个Supergrid控件 2.添加列ID,NAME,MATH,CN,SEX 3.在任务窗格中勾选“Show Tree Lines”和“Show Tree Buttons” 4.添加数据 ...
- linux 6.5上创建新用户后,不能登陆？
linux 6.5上创建新用户后,不能登陆? 使用root账户登陆却可以! [root@ log]# useradd mtdk[root@ log]# echo 123abc |passwd --st ...
- ThinkPHP模板的知识
php框架 一.真实项目开发步骤: 多人同时开发项目,协作开发项目.分工合理.效率有提高(代码风格不一样.分工不好) 测试阶段 上线运行 对项目进行维护.修改.升级(单个人维护项目,十分困难,代码风格 ...
- 【docker】将Java jar文件生成镜像、上传镜像并生成镜像压缩文件
概述 将Springboot的web服务打包成Jar包后,自动化脚本将jar打包成镜像.上传镜像.并生成镜像的压缩文件: Dockerfile FROM 10.254.9.21/library/ora ...