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 ...

随机推荐

Oracle Shared Pool之Library Cache
1. Shared Pool组成 Shared Pool由许多区间(Extent)组成,这些区间又由多个连续的内存块(Chunk)组成,这些内存块大小不一.从逻辑功能角度,Shared pool主要包 ...
ntpd修改版本号教程
1.查看当前ntpd版本号执行:ntpd -v 2.查看当前ntpd位置执行:which ntpd 3.备份ntpd 执行:cp /usr/sbin/ntpd /usr/sbin/ntpd.bak ...
swftools安装教程
1 安装说明本教程以环境为CentOS6.5+swftools-0.9.1.安装目录等可根据自己需要更改. 2 安装过程 1)下载软件 http://www.swftools.org/downloa ...
返回JSON格式（二十五）
在上述例子中,通过@ControllerAdvice统一定义不同Exception映射到不同错误处理页面.而当我们要实现RESTful API时,返回的错误是JSON格式的数据,而不是HTML页面,这 ...
textarea输入框限制字数
<textarea onkeyup="checkLen(this)"></textarea> <div>您还可以输入 <span id=& ...
五笔xu
1● 横 a s d f g 半包围上下左右 2● 竖 h j k l m 左右上下半包围 3● 撇 q w e r t 半包围上下左右 4● 捺 y u ...
Java Date实现加一天,年月日类推往后+1,日期+1,月份+1,年份+1
System.out.println("String类型 "+endDate); //页面传递到后台的时间为String类型 SimpleDateFormat sdf = new ...
Entrust - Laravel 用户权限系统解决方案
Zizaco/Entrust 是 Laravel 下用户权限系统的解决方案, 配合用户身份认证扩展包 Zizaco/confide 使用, 可以快速搭建出一套具备高扩展性的用户系统. Conf ...
how to get ubuntu current default runlevel
[Purpose] Learning how to get ubuntu current default runlevel [Eevironment] Ubuntu 1 ...
asp.net中javascript与后台c#交互
asp.net中javascript与后台c#交互作者:熊猫大叔字体:[增加减小] 类型:转载时间:2015-10-23我要评论,出处:http://www.jb51.net/article/ ...

hint不当索引，影响多表连接方式，最终导致SQL执行缓慢

hint不当索引，影响多表连接方式，最终导致SQL执行缓慢的更多相关文章

随机推荐

热门专题