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 ...
随机推荐
- 跳转到页面的某个anchor
var loc = document.location.toString().split('#')[0]; document.location = loc + '#' + anchor;
- RCNN 目标识别基本原理
RCNN- 将CNN引入目标检测的开山之作 from:https://zhuanlan.zhihu.com/p/23006190 前面一直在写传统机器学习.从本篇开始写一写 深度学习的内容. 可能需要 ...
- python实现简单的聊天小程序
概要 这是一个使用python实现一个简单的聊天室的功能,里面包含群聊,私聊两种聊天方式.实现的方式是使用套接字编程的一个使用TCP协议 c/s结构的聊天室 实现思路 x01 服务端的建立 首先,在服 ...
- 从此web开发so easy!
ECharts (Enterprise Charts 商业产品图表库) 基于Canvas,纯Javascript图表库,提供直观,生动,可交互,可个性化定制的数据可视化图表.创新的拖拽重计算.数据视图 ...
- hashlib 库
hashlib 库 hash 是一种算法,用来接收一系列数据,经过计算后得到一个hash值 hash值的三大特征: 1. 如果传入的数据一样,得到的hash值一样 2. 只要采用的hash算法固定,无 ...
- vue 小知识
图片: 1.img 的路径 <img :src="item.src"/> 2.背景图片的路径 v-bind:style="{backgroundImage: ...
- 回声UDP服务器端/客户端
UDP是具有数据边界的协议,传输中调用I/O函数的次数非常重要.输入函数的调用次数要和输出函数的调用次数完全一致,这样才能保证接受全部已发送的数据. TCP套接字中需注册待传输数据的目标IP和端口,而 ...
- Win10系列：UWP界面布局基础3
在实际项目开发中,为控件属性赋值时经常会遇到属性值在设计时处于未知状态,而只有在应用程序运行时才能获取到.这种情况下,直接赋值方法是无法满足的,可以使用XAML标记扩展(Markup Extensio ...
- php 图片添加水印和二维码
$host = $_SERVER['HTTP_HOST']; $save_code_file = './qrcodes/qrcode.png'; QrCode::format()->backgr ...
- hMailServer 配置
本例记录如何通过 [hMailServer] 在私有服务器中搭建邮件服务器 1.下载安装包 版本: hMailServer-5.6.7-B2425.exe (支持使用内置数据库) , 安装时,设置管 ...