hint不当索引，影响多表连接方式，最终导致SQL执行缓慢
需求：一个SQL执行特别慢，无法返回结果，需要进行优化，最终返回结果即可。
一、SQL分析
二、尝试执行，观测执行计划
三、修改SQL
四、问题总结
一、SQL分析
）SQL文本，执行时间，执行用户
用户brjljk sql执行时间，2935分钟
sql_text
select c.hphm,
c.ccdjrq,
c.clpp1,
c.clxh,
c.zt,
c.syr,
c.wfsj,
c.wfxw,
c.dsr,
c.xxly,
c.syq,
c.wfsj1,
d.wfnr,
e.dlmc,
c.xxly1,
c.dsr1
from (select /*+ index(b idx_violation_wfsj)*/
a.hphm,
a.ccdjrq,
a.clpp1,
a.clxh,
a.zt,
a.syr,
a.wfsj,
a.wfxw,
a.dsr,
a.xxly,
a.syq,
b.wfsj wfsj1,
b.wfxw wfxw1,
b.wfdd wfdd1,
b.xxly xxly1,
b.dsr dsr1
from A a
right join B b
on a.hphm = b.hphm
where a.wfsj <> b.wfsj
and (b.wfsj < add_months(a.wfsj, ) and
b.wfsj > add_months(a.wfsj, -))
and a.wfsj > to_date('2018-08-01', 'yyyy-mm-dd')
and a.wfsj < to_date('2018-09-01', 'yyyy-mm-dd')
order by a.hphm, a.wfsj, b.wfsj) c,
D d,
E e
where c.wfxw1 = d.wfxw
and c.wfdd1 = e.dldm 2）查询会话等待事件
SQL> select sid,serial#,event,sql_id,status,(sysdate-logon_time)*86400 as "s",
last_call_et,username,inst_id,MACHINE from gv$session where status='ACTIVE' and username is not null;
SID SERIAL# EVENT SQL_ID STATUS s LAST_CALL_ET USERNAME INST_ID MACHINE
---------- ---------- ------------------------------ ------------- -------- ---------- -------
1776 28345 db file sequential read 2vcdzpaknk46s ACTIVE 180100 176352 xxx 1 xx
3)查询sql文本
SQL> select sql_text from v$sqlarea where sql_id ='&a';
SQL> select sql_text from v$sqltext where sql_id ='2vcdzpaknk46s';
SQL> select sql_text from v$sqlstats where sql_id ='2vcdzpaknk46s';
4）查询执行计划
select * from table(dbms_xplan.display_cursor('&sql',null,'PEEKED_BINDS'));
SQL> select * from table(dbms_xplan.display_awr('2vcdzpaknk46s',null));
------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | | 129M(100)| |
| 1 | SORT ORDER BY | | 309 | 56238 | 129M (1)|432:58:14 |
| 2 | HASH JOIN | | 309 | 56238 | 129M (1)|432:58:14 |
| 3 | HASH JOIN | | 309 | 50985 | 129M (1)|432:58:13 |
| 4 | HASH JOIN | | 309 | 37389 | 129M (1)|432:58:13 |
| 5 | TABLE ACCESS FULL | SJS20181022 | 10455 | 847K| 891 (2)| 00:00:11 |
| 6 | TABLE ACCESS BY INDEX ROWID| VIO_VIOLATION | 144M| 5226M| 129M (1)|432:57:51 |
| 7 | INDEX FULL SCAN | IDX_VIOLATION_WFSJ | 144M| | 583K (1)| 01:56:47 |
| 8 | TABLE ACCESS FULL | VIO_CODEWFDM | 1069 | 47036 | 13 (0)| 00:00:01 |
| 9 | TABLE ACCESS FULL | FRM_ROADITEM | 5212 | 88604 | 22 (0)| 00:00:01 |
------------------------------------------------------------------------------------------------------
5）查询SQL等待事件
select count(*),event,count(distinct session_id) from gv$active_session_history
where sql_id='2vcdzpaknk46s' group by event;
COUNT(*) EVENT COUNT(DISTINCTSESSION_ID)
---------- ------------------------------ -------------------------
27652 db file sequential read 1
22 gc cr block 2-way 1
258 gc cr disk read 1
293 1
6）查询执行计划最慢的步骤（failed）
select count(*),sql_plan_line_id
from gv$active_session_history
where sql_id='2vcdzpaknk46s'
group by sql_plan_line_id
order by 2;
--生产环境10.2.0.5，11g才有的字段
7）表碎片
表碎片会导致全表扫描更消耗资源，本次慢不是由于全表扫描的问题
8）数据量
通过dba_tables,num_rows,dba_segments,bytes查询得到信息如下
a表 hash join 驱动表，30万条记录
B表 hash join 被驱动表，1亿条记录，表100G大小
二、尝试执行，观测执行计划
1）确认优化重点四个表中，从执行计划看，重点为
| 6 | TABLE ACCESS BY INDEX ROWID| VIO_VIOLATION | 144M| 5226M| 129M (1)|432:57:51 |
| 7 | INDEX FULL SCAN | IDX_VIOLATION_WFSJ | 144M| | 583K (1)| 01:56:47 |
该SQL是a +b 的集合，转换为c最后与其它表进行关联查询 2）对a+b表的查询进行优化及测试 思路A，是否由于时间取值范围导致的问题
and (b.wfsj < add_months(a.wfsj, 12) and
b.wfsj > add_months(a.wfsj, -12))
and a.wfsj > to_date('2018-08-01', 'yyyy-mm-dd')
and a.wfsj < to_date('2018-09-01', 'yyyy-mm-dd') explain plan for select a.hphm,a.wfsj,b.wfsj from A a right join B b on a.hphm=b.hphm where b.wfsj > to_date('2017-01-01','yyyy-mm-dd') and b.wfsj <to_date('2019-01-01','yyyy-mm-dd') and a.wfsj>to_date('2018-08-01','yyyy-mm-dd') and a.wfsj<to_date('2018-09-01','yyyy-mm-dd') order by a.hphm,a.wfsj, b.wfsj; 1* select * from table(dbms_xplan.display()) PLAN_TABLE_OUTPUT
----------------------------------------------------------------------
Plan hash value: 1015943026 -----------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-----------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 18958 | 629K| 115K (1)| 00:23:12 |
| 1 | SORT ORDER BY | | 18958 | 629K| 115K (1)| 00:23:12 |
|* 2 | TABLE ACCESS BY INDEX ROWID| VIO_VIOLATION | 2 | 34 | 13 (0)| 00:00:01 |
| 3 | NESTED LOOPS | | 18958 | 629K| 115K (1)| 00:23:12 |
|* 4 | INDEX FAST FULL SCAN | SJS20181022_IND_HPHM | 10455 | 173K| 277 (2)| 00:00:04 |
|* 5 | INDEX RANGE SCAN | IDX_VIOLATION_HPHM | 12 | | 3 (0)| 00:00:01 |
----------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id):
--------------------------------------------------- 2 - filter("B"."WFSJ">TO_DATE(' 2017-01-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
"B"."WFSJ"<TO_DATE(' 2019-01-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
4 - filter("A"."WFSJ">TO_DATE(' 2018-08-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
"A"."WFSJ"<TO_DATE(' 2018-09-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
5 - access("A"."HPHM"="B"."HPHM") select * from table(dbms_xplan.display_cursor('004nmwuabm1qr',null,'PEEKED_BINDS')) PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------------------------
SQL_ID 004nmwuabm1qr, child number 0
-------------------------------------
select a.hphm, a.ccdjrq, a.clpp1, a.clxh, a.zt,
a.syr, a.wfsj, a.wfxw, a.dsr, a.xxly,
a.syq, b.wfsj wfsj1, b.wfxw wfxw1, b.wfdd wfdd1,
b.xxly xxly1, b.dsr dsr1 from A a right join
B b on a.hphm=b.hphm where (b.wfsj < add_months(a.wfsj, 12) and
b.wfsj >add_months(a.wfsj, -12)) and a.wfsj>to_date('2018-08-01','yyyy-mm-dd') and
a.wfsj<to_date('2018-09-01','yyyy-mm-dd') order by a.hphm,a.wfsj, b.wfsj Plan hash value: 3321285990 PLAN_TABLE_OUTPUT
-------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | | 136K(100)| |
| 1 | SORT ORDER BY | | 309 | 37389 | 136K (1)| 00:27:23 |
|* 2 | TABLE ACCESS BY INDEX ROWID| VIO_VIOLATION | 1 | 38 | 13 (0)| 00:00:01 |
| 3 | NESTED LOOPS | | 309 | 37389 | 136K (1)| 00:27:23 |
|* 4 | TABLE ACCESS FULL | SJS20181022 | 10455 | 847K| 891 (2)| 00:00:11 |
|* 5 | INDEX RANGE SCAN | IDX_VIOLATION_HPHM | 12 | | 3 (0)| 00:00:01 |
---------------------------------------------------------------------------------
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Predicate Information (identified by operation id):
--------------------------------------------------- 2 - filter(("B"."WFSJ"<ADD_MONTHS(INTERNAL_FUNCTION("A"."WFSJ"),12) AND
"B"."WFSJ">ADD_MONTHS(INTERNAL_FUNCTION("A"."WFSJ"),-12)))
4 - filter(("A"."WFSJ">TO_DATE(' 2018-08-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss')
AND
"A"."WFSJ"<TO_DATE(' 2018-09-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss')))
5 - access("A"."HPHM"="B"."HPHM") 32 rows selected. 结论A的考虑是错误的，add_months并不会导致执行计划消耗更多的资源 思路B：多表连接的问题？ 让sql从hash join 转换为nest loop试试，本次sql 取消hint即可，
为了不增加服务器负担，
使用explain plan for 方式 SQL> explain plan for select a.hphm,a.wfsj,b.wfsj from A a
right join B b on a.hphm=b.hphm
where (b.wfsj < add_months(a.wfsj, 12) and b.wfsj >add_months(a.wfsj, -12))
and a.wfsj>to_date('2018-08-01','yyyy-mm-dd')
and a.wfsj<to_date('2018-09-01','yyyy-mm-dd') order by a.hphm,a.wfsj, b.wfsj; Explained. SQL> select * from table(dbms_xplan.display()); PLAN_TABLE_OUTPUT
---------------------------------------------------------------------------
Plan hash value: 1015943026
---------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 309 | 10506 | 115K (1)| 00:23:12 |
| 1 | SORT ORDER BY | | 309 | 10506 | 115K (1)| 00:23:12 |
|* 2 | TABLE ACCESS BY INDEX ROWID| VIO_VIOLATION | 1 | 17 | 13 (0)| 00:00:01 |
| 3 | NESTED LOOPS | | 309 | 10506 | 115K (1)| 00:23:12 |
|* 4 | INDEX FAST FULL SCAN | SJS20181022_IND_HPHM | 10455 | 173K| 277 (2)| 00:00:04 |
|* 5 | INDEX RANGE SCAN | IDX_VIOLATION_HPHM | 12 | | 3 (0)| 00:00:01 |
--------------------------------------------------------------------------------- Predicate Information (identified by operation id):
--------------------------------------------------- 2 - filter("B"."WFSJ"<ADD_MONTHS(INTERNAL_FUNCTION("A"."WFSJ"),12) AND
"B"."WFSJ">ADD_MONTHS(INTERNAL_FUNCTION("A"."WFSJ"),-12))
4 - filter("A"."WFSJ">TO_DATE(' 2018-08-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
"A"."WFSJ"<TO_DATE(' 2018-09-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
5 - access("A"."HPHM"="B"."HPHM") 21 rows selected. 发现nest loop 方式挺快的，继续测试（上述测试只测试3个字段） 使用原SQLa+b的两个表SQL不做变动，执行测试，发现执行计划未改变； 使用需要优化的SQL文本，删除hint，进行explain plan for 进行测试，执行计划未改变
三、修改SQL
删除Hint，让SQL走nest loop 方式，10s内返回结果
SQL> select c.hphm,
c.ccdjrq,
c.clpp1,
c.clxh,
c.zt,
c.syr,
c.wfsj,
c.wfxw,
c.dsr,
c.xxly,
c.syq,
c.wfsj1,
d.wfnr,
e.dlmc,
c.xxly1,
c.dsr1
from (select
a.hphm,
a.ccdjrq,
a.clpp1,
a.clxh,
a.zt,
a.syr,
a.wfsj,
a.wfxw,
a.dsr,
a.xxly,
a.syq,
b.wfsj wfsj1,
b.wfxw wfxw1,
b.wfdd wfdd1,
b.xxly xxly1,
b.dsr dsr1
from A a
right join B b
on a.hphm = b.hphm
where a.wfsj <> b.wfsj
and (b.wfsj < add_months(a.wfsj, 12) and
b.wfsj > add_months(a.wfsj, -12))
and a.wfsj > to_date('2018-08-01', 'yyyy-mm-dd')
and a.wfsj < to_date('2018-09-01', 'yyyy-mm-dd')
order by a.hphm, a.wfsj, b.wfsj) c,
D d,
E e
where c.wfxw1 = d.wfxw
and c.wfdd1 = e.dldm;
52519 rows selected.
Elapsed: 00:00:05.08 Execution Plan
----------------------------------------------------------
Plan hash value: 2181500870 -----------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-----------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 309 | 56238 | 136K (1)| 00:27:24 |
| 1 | SORT ORDER BY | | 309 | 56238 | 136K (1)| 00:27:24 |
|* 2 | HASH JOIN | | 309 | 56238 | 136K (1)| 00:27:24 |
|* 3 | HASH JOIN | | 309 | 50985 | 136K (1)| 00:27:23 |
|* 4 | TABLE ACCESS BY INDEX ROWID| VIO_VIOLATION | 1 | 38 | 13 (0)| 00:00:01 |
| 5 | NESTED LOOPS | | 309 | 37389 | 136K (1)| 00:27:23 |
|* 6 | TABLE ACCESS FULL | SJS20181022 | 10455 | 847K| 891 (2)| 00:00:11 |
|* 7 | INDEX RANGE SCAN | IDX_VIOLATION_HPHM | 12 | | 3 (0)| 00:00:01 |
| 8 | TABLE ACCESS FULL | VIO_CODEWFDM | 1069 | 47036 | 13 (0)| 00:00:01 |
| 9 | TABLE ACCESS FULL | FRM_ROADITEM | 5212 | 88604 | 22 (0)| 00:00:01 |
----------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id):
--------------------------------------------------- 2 - access("B"."WFDD"="E"."DLDM")
3 - access("B"."WFXW"="D"."WFXW")
4 - filter("A"."WFSJ"<>"B"."WFSJ" AND "B"."WFSJ"<ADD_MONTHS(INTERNAL_FUNCTION("A"."WFSJ"),
12) AND "B"."WFSJ">ADD_MONTHS(INTERNAL_FUNCTION("A"."WFSJ"),-12))
6 - filter("A"."WFSJ">TO_DATE(' 2018-08-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
"A"."WFSJ"<TO_DATE(' 2018-09-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
7 - access("A"."HPHM"="B"."HPHM") Statistics
----------------------------------------------------------
1 recursive calls
0 db block gets
211168 consistent gets
108 physical reads
116 redo size
3555229 bytes sent via SQL*Net to client
39003 bytes received via SQL*Net from client
3503 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
52519 rows processed
四、问题总结
1）使用Nest loop方式，被驱动表及时循环查询30万次，比想象中的快很多很多
2）本次sql未优化前走hash join方式的原因是，hint 索引是时间列，
而Nest loop方式需要驱动表的查询结果输出身份证，被驱动表拿着身份证，
去被驱动表中索取记录；驱动表在本次执行计划无变化，被驱动表从时间字段索引，转换走
IDX_VIOLATION_HPHM， 也就是说，由于索引的选择度的问题，Oracle认为 hash join的连接方式
优于 date索引（hint）找到对应的rowid,然后找到hphm字段值
3）今后，在使用hint前，通过测试，选择合适的hint
hint不当索引，影响多表连接方式，最终导致SQL执行缓慢的更多相关文章
- Oracle 表连接方式分析 .
一 引言 数据仓库技术是目前已知的比较成熟和被广泛采用的解决方案,用于整和电信运营企业内部所有分散的原始业务数据,并通过便捷有效的数据访问手段,可以支持企业内部不同部门,不同需求,不同层次的用户随时获 ...
- 看懂Oracle执行计划、表连接方式
看懂Oracle执行计划 原文:https://www.cnblogs.com/Dreamer-1/p/6076440.html 最近一直在跟Oracle打交道,从最初的一脸懵逼到现在的略有所知,也 ...
- Oracle的表连接方式
Oracle的表连接方式: 1.Nl Join连接(嵌套连接) 2.Hash Join(哈希连接) 3.Merge Sort Join(排序合并连接) 各种连接的使用场景: 1. 排序合并连接是偏向于 ...
- Oracle多种表连接方式
1. 内连接(自然连接) 2. 外连接 (1)左外连接 (左边的表不加限制) (2)右外连接(右边的表不加限制) (3)全外连接(左右两表都不加限制) 3. 自连接(同一张表内的连接) SQL的标准语 ...
- 数据库基础知识详解三：MVCC、范式以及表连接方式
写在文章前:本系列文章用于博主自己归纳复习一些基础知识,同时也分享给可能需要的人,因为水平有限,肯定存在诸多不足以及技术性错误,请大佬们及时指正. 8.MVCC 多版本并发控制(Multi-Versi ...
- sql表连接方式
表连接有几种? sql表连接分成外连接.内连接和交叉连接. 一.外连接 概述: 外连接包括三种,分别是左外连接.右外连接.全外连接. 对应的sql关键字:LEFT/RIGHT/FULL OUTER ...
- 数据库多表连接方式介绍－HASH-JOIN
1.概述 hash join是一种数据库在进行多表连接时的处理算法,对于多表连接还有两种比较常用的方式:sort merge-join 和 nested loop. 为了比较清楚的介绍hash joi ...
- oracle执行计划之-表连接方式
转载自:http://blog.csdn.net/tianlesoftware/article/details/5826546 在多表联合查询的时候,如果我们查看它的执行计划,就会发现里面有多表之间的 ...
- SQLAlchemy（2）：多表操作 & 连接方式及原生SQL
一对多:ForeignKey multitb_models.py import datetime from sqlalchemy import create_engine # 引入 创建引擎 from ...
随机推荐
- 三、持久层框架（Hibernate）
一.Hibernate处理关系 关系主要有三种:1.多对一 2.一对多 3.多对多 1.多对一 一个Product对应一个Category,一个Category对应多个Product(一个产品对应一个 ...
- 第2天【OS Linux发行版介绍、Linux系统基础使用入门、Linux命令帮助、Linux基础命令】
Logout 退出系统 Gedit 文本编辑器工具 Uname –r 查看内核版本信息,uname –a 比较详细 Cat /proc/cpuinfo 查看CPU Cat /p ...
- Django之路由分配系统
前言: Django大致工作流程 1.客户端发送请求(get/post)经过web服务器.Django中间件. 到达路由分配系统 2.路由分配系统根据提取 request中携带的的url路径(path ...
- listener.ora和tnsnames.ora格式解析
listener.ora是oracle数据库服务端的监听配置文件,包括协议.IP地址和端口等内容:tnsnames.ora是oracle数据库客户端的连接配置文件,也是对应的协议.IP地址和端口等内容 ...
- 把旧系统迁移到.Net Core 2.0 日记（6) MapRoute/Area/ViewPath
我想实现 http://localhost:5000/{moduleName}/{controller}/{action}/{id?} 这样的url. 有2个方法 方法1: 在路由里设置多个modul ...
- 由@Convert注解引出的jackson对枚举的反序列化规则
对于一些状态字段以前时兴用常量,现在时兴用枚举,虽然阅读体验极佳,但是传值的时候还是会有些麻烦,需要设置一下转换器.比如: class A{ @Convert(converter=TestTypeCo ...
- XIA.人机猜拳
package test1_game; /** * 电脑玩家类 * * @author ljj * */ import java.util.Scanner; public class Computer ...
- javascript 日期函数
获取当前日期的前一天的日期 var MyDate = new Date( ); //获取昨天的日期 var yesterday = myDate.getTime()-1000*60*60 ...
- HTML代码转换为JavaScript字符串
我有时在工作中用到字符串拼接基本上来自于此,链接 http://www.css88.com/tool/html2js/
- day02 运算符和编码
今日所学 主要是运算符和编码的初认识, 1 还有比较运算 ==,!=,<>,>,<,>=,<=等 2 . 赋值运算 =,+=,-=等 还有今天的难点逻辑运算 ...