oracle关联表不走索引,此SQL为什么走全表不走索引呢

最新推荐文章于 2023-06-14 15:59:20 发布
最新推荐文章于 2023-06-14 15:59:20 发布
阅读量820 收藏
点赞数
文章标签： oracle关联表不走索引

本帖最后由 flzhang 于 2015-10-15 10:59 编辑

如下SQL为什么三个表放一起连接 RW_BI_FT_LT就走全表扫描，而改写成只有T1和T2连接后，RW_BI_FT_LT就能走索引呢?

改写前

SELECT

T1.SERL_NO

,T1.SI_YMD

,T1.ST_YMD

,T1.ST2_YMD

,T1.SO_YMD

,T1.ACTU_DT    FOTA_DT

,T2.SALE_YMD  CHANEL_SO

,T2.REGI_DT   CHANEL_SO_REGI_DT

FROMMCS_BI.RW_BI_FT_LT T1

,MCS_HQ.HI_SALE_CHNL T2

,MCS_HQ_READ.UP_LOAD_SERL10 T3

WHERET1.SERL_NO = T2.SERL_NO(+)

AND   T3.SERL_NO = T1.SERL_NO(+);

执行计划

Execution Plan

----------------------------------------------------------

Plan hash value: 3150097070

--------------------------------------------------------------------------------

-----------------------------------------

| Id  | Operation                           | Name              | Rows  | Bytes

| Cost (%CPU)| Time     | Pstart| Pstop |

--------------------------------------------------------------------------------

-----------------------------------------

|   0 | SELECT STATEMENT                    |                   |    63 |  8316

|   257K  (1)| 00:51:31 |       |       |

|   1 |  NESTED LOOPS OUTER                 |                   |    63 |  8316

|   257K  (1)| 00:51:31 |       |       |

|*  2 |   HASH JOIN OUTER                   |                   |    63 |  6237

|   257K  (1)| 00:51:30 |       |       |

|   3 |    TABLE ACCESS FULL                | UP_LOAD_SERL10    |    63 |  3276

|     3   (0)| 00:00:01 |       |       |

|   4 |    PARTITION RANGE ALL              |                   |    38M|  1725M

|   257K  (1)| 00:51:27 |     1 |   122 |

|   5 |     TABLE ACCESS FULL               | RW_BI_FT_LT       |    38M|  1725M

|   257K  (1)| 00:51:27 |     1 |   122 |

|   6 |   TABLE ACCESS BY GLOBAL INDEX ROWID| HI_SALE_CHNL      |     1 |    33

|     2   (0)| 00:00:01 | ROWID | ROWID |

|*  7 |    INDEX UNIQUE SCAN                | UX_HI_SALE_CHNL_1 |     1 |

|     1   (0)| 00:00:01 |       |       |

--------------------------------------------------------------------------------

-----------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

2 - access("T3"."SERL_NO"="T1"."SERL_NO"(+))

7 - access("T1"."SERL_NO"="T2"."SERL_NO"(+))

Note

-----

- dynamic sampling used for this statement (level=2)

Statistics

----------------------------------------------------------

7  recursive calls

0  db block gets

1171799  consistent gets

1171265  physical reads

196  redo size

3070  bytes sent via SQL*Net to client

268  bytes received via SQL*Net from client

6  SQL*Net roundtrips to/from client

0  sorts (memory)

0  sorts (disk)

63  rows processed

实际执行计划

Plan hash value: 3150097070

----------------------------------------------------------------------------------------------------------------------------

| Id  | Operation                           | Name              | Starts | E-Rows | A-Rows |   A-Time   | Buffers | Reads  |

----------------------------------------------------------------------------------------------------------------------------

|   0 | SELECT STATEMENT                    |                   |      1 |        |     63 |00:01:35.15 |    1173K|   1173K|

|   1 |  NESTED LOOPS OUTER                 |                   |      1 |     63 |     63 |00:01:35.15 |    1173K|   1173K|

|*  2 |   HASH JOIN OUTER                   |                   |      1 |     63 |     63 |00:01:34.96 |    1173K|   1173K|

|   3 |    TABLE ACCESS FULL                | UP_LOAD_SERL10    |      1 |     63 |     63 |00:00:00.01 |       7 |      0 |

|   4 |    PARTITION RANGE ALL              |                   |      1 |     38M|     38M|00:01:13.83 |    1173K|   1173K|

|   5 |     TABLE ACCESS FULL               | RW_BI_FT_LT       |    122 |     38M|     38M|00:01:03.25 |    1173K|   1173K|

|   6 |   TABLE ACCESS BY GLOBAL INDEX ROWID| HI_SALE_CHNL      |     63 |      1 |     63 |00:00:00.19 |     191 |     24 |

|*  7 |    INDEX UNIQUE SCAN                | UX_HI_SALE_CHNL_1 |     63 |      1 |     63 |00:00:00.19 |     128 |     24 |

----------------------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

2 - access("T3"."SERL_NO"="T1"."SERL_NO")

7 - access("T1"."SERL_NO"="T2"."SERL_NO")

Note

-----

- dynamic sampling used for this statement (level=2)

改写后SQL

WITH T_MAST AS (

SELECTT1.SERL_NO

,T1.SI_YMD

,T1.ST_YMD

,T1.ST2_YMD

,T1.SO_YMD

,T1.ACTU_DT    FOTA_DT

,T2.SALE_YMD  CHANEL_SO

,T2.REGI_DT   CHANEL_SO_REGI_DT

FROMMCS_BI.RW_BI_FT_LT T1

,MCS_HQ.HI_SALE_CHNL T2

WHERET1.SERL_NO = T2.SERL_NO(+)

)

SELECTT_MAST.*

FROMT_MAST,

MCS_HQ_READ.UP_LOAD_SERL10 T2

WHERE    T_MAST.SERL_NO(+) = T2.SERL_NO;

对应执行计划

Execution Plan

----------------------------------------------------------

Plan hash value: 2281879921

--------------------------------------------------------------------------------

-------------------------------------------

| Id  | Operation                             | Name              | Rows  | Byte

s | Cost (%CPU)| Time     | Pstart| Pstop |

--------------------------------------------------------------------------------

-------------------------------------------

|   0 | SELECT STATEMENT                      |                   |    63 |  768

6 | 25779   (1)| 00:05:10 |       |       |

|   1 |  NESTED LOOPS OUTER                   |                   |    63 |  768

6 | 25779   (1)| 00:05:10 |       |       |

|   2 |   TABLE ACCESS FULL                   | UP_LOAD_SERL10    |    63 |  327

6 |     2   (0)| 00:00:01 |       |       |

|   3 |   VIEW PUSHED PREDICATE               |                   |     1 |    7

0 |   409   (0)| 00:00:05 |       |       |

|   4 |    NESTED LOOPS OUTER                 |                   |     1 |    8

0 |   409   (0)| 00:00:05 |       |       |

|   5 |     PARTITION RANGE ALL               |                   |     1 |    4

7 |   407   (0)| 00:00:05 |     1 |   122 |

|   6 |      TABLE ACCESS BY LOCAL INDEX ROWID| RW_BI_FT_LT       |     1 |    4

7 |   407   (0)| 00:00:05 |     1 |   122 |

|*  7 |       INDEX SKIP SCAN                 | PK_RW_BI_FT_LT    |     1 |

|   405   (0)| 00:00:05 |     1 |   122 |

|   8 |     TABLE ACCESS BY GLOBAL INDEX ROWID| HI_SALE_CHNL      |     1 |    3

3 |     2   (0)| 00:00:01 | ROWID | ROWID |

|*  9 |      INDEX UNIQUE SCAN                | UX_HI_SALE_CHNL_1 |     1 |

|     1   (0)| 00:00:01 |       |       |

--------------------------------------------------------------------------------

-------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

7 - access("T1"."SERL_NO"="T2"."SERL_NO")

filter("T1"."SERL_NO"="T2"."SERL_NO")

9 - access("T2"."SERL_NO"(+)="T2"."SERL_NO")

filter("T1"."SERL_NO"="T2"."SERL_NO"(+))

Note

-----

- dynamic sampling used for this statement (level=2)

Statistics

----------------------------------------------------------

20  recursive calls

2  db block gets

96259  consistent gets

2620  physical reads

0  redo size

2920  bytes sent via SQL*Net to client

268  bytes received via SQL*Net from client

6  SQL*Net roundtrips to/from client

0  sorts (memory)

0  sorts (disk)

实际执行计划

Plan hash value: 2281879921

------------------------------------------------------------------------------------------------------------------------------

| Id  | Operation                             | Name              | Starts | E-Rows | A-Rows |   A-Time   | Buffers | Reads  |

------------------------------------------------------------------------------------------------------------------------------

|   0 | SELECT STATEMENT                      |                   |      1 |        |     63 |00:00:23.39 |   96374 |   2705 |

|   1 |  NESTED LOOPS OUTER                   |                   |      1 |     63 |     63 |00:00:23.39 |   96374 |   2705 |

|   2 |   TABLE ACCESS FULL                   | UP_LOAD_SERL10    |      1 |     63 |     63 |00:00:00.01 |       7 |      0 |

|   3 |   VIEW PUSHED PREDICATE               |                   |     63 |      1 |     63 |00:00:23.39 |   96367 |   2705 |

|   4 |    NESTED LOOPS OUTER                 |                   |     63 |      1 |     63 |00:00:23.39 |   96367 |   2705 |

|   5 |     PARTITION RANGE ALL               |                   |     63 |      1 |     63 |00:00:23.17 |   96183 |   2679 |

|   6 |      TABLE ACCESS BY LOCAL INDEX ROWID| RW_BI_FT_LT       |   7686 |      1 |     63 |00:00:23.16 |   96183 |   2679 |

|*  7 |       INDEX SKIP SCAN                 | PK_RW_BI_FT_LT    |   7686 |      1 |     63 |00:00:22.93 |   96121 |   2632 |

|   8 |     TABLE ACCESS BY GLOBAL INDEX ROWID| HI_SALE_CHNL      |     63 |      1 |     63 |00:00:00.22 |     184 |     26 |

|*  9 |      INDEX UNIQUE SCAN                | UX_HI_SALE_CHNL_1 |     63 |      1 |     63 |00:00:00.22 |     121 |     26 |

------------------------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

7 - access("T1"."SERL_NO"="T2"."SERL_NO")

filter("T1"."SERL_NO"="T2"."SERL_NO")

9 - access("T2"."SERL_NO"="T2"."SERL_NO")

filter("T1"."SERL_NO"="T2"."SERL_NO")

Note

-----

- dynamic sampling used for this statement (level=2)

weixin_39968852
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
oracle表关联为什么不走索引,Oracle执行计划不走索引的原因总结
weixin_29713915的博客
04-09 2865
51Testing软件测试网\2cGa+\2o在操作中，为什么有时一个表的某个字段明明有索引，当观察一些语的执行计划确不走索引呢？如何解决呢？本文我们主要就介绍这部分内容，接下来就让我们一起来了解一下。51Testing软件测试网}6M/l0f2rh$D#^7R9ye"?;}0不走索引大体有以下几个原因：1qH+L{8]^-^0|:\9wN/~!LAq0你在Instance级别所用的是all_ro...
oracle多表索引查询语句,大神求助，oracle多表关联，不走索引和语句如何优化
weixin_30451613的博客
04-15 923
sql语句SELECT *FROM (SELECT GROUPER.*,ROW_NUMBER() OVER(PARTITION BY GROUPER.GENERAL_BIZ_NUM, GROUPER.comment_issuer_role_cd ORDER BY GROUPER.comment_issuing_time DESC) AS ROWNUMBERFROM (select temp.gen...
oracle 关联加索引,为什么建了索引，并且关联条件也是索引关联，却不使用索引关联呢。...
weixin_28728031的博客
04-03 262
BANNER--------------------------------------------------------------------------------------------------------------------------------Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64biPL...
ORACLE 不走索引（失效）的原因以及解决办法
热门推荐
u011954243的博客
07-12 2万+
今天在做程序的时候发现原先写的索引竟然莫名奇妙地失效了。去找了一下大概原因如下，做了分析心得写上，希望能帮助大家 首先了解失效索引的原因   1,   2,单独的>,   3,like "%_" 百分号在前.  4,表没分析.  5,单独引用复合索引里非第一位置的索引列. 6,字符型字段为数字时在where条件里不添加引号. 7,对索引列进行运算.需要建
Oracle执行计划不走索引的原因总结
12-14
在Oracle数据库操作中，为什么有时一个表的某个字段明明有索引，当观察一些语的执行计划确不走索引呢？如何解决呢？本文我们主要介绍这部分内容，接下来让我们一起来了解一下。 　　不走索引大体有以下几个原因： 　　你在Instance级别所用的是all_rows的方式 　　你的表的统计信息（可能的原因） 　　你的表很小，上文提到过的，Oracle的优化器认为不值得走索引。 　　解决方法： 　　可以修改init.ora中的OPTIMIZER_MODE这个参数，把它改为Rule或Choose，重起数据库。也可以使用4中所提的Hint。 　　不走索引的其它原因： 　　1、
Oracle SQL建立有效索引减少回表
12-14
回表：在数据中，当查询数据的时候，在索引中查找索引后，获得该行的rowid，根据rowid再查询表中数据，是回表。... 　如果在b上没有建立索引，那么该条SQL语句执行时，要进行全表扫描，扫描所有该表中的数据块
详解sqlserver查询表索引
12-15
SELECT 索引名称=a.name  ,表名=c.name  ,索引字段名=d.name  ,索引字段位置=d.colid  FROM sysindexes a JOIN sysindexkeys b ON a.id=b.id AND a.indid=b.indid JOIN sysobjects c ON b.id=c.id JOIN ...
oracle用什么SQL语句判断表存不存在
12-16
正在看的ORACLE教程是:oracle用什么SQL语句判断表存不存在。SQL SERVER用来判断表或视图存在的语句在ORACLE中不能用，请问该怎么写。 谢谢。 提问者： – 最佳答案 exists(select tname from tab where tname =’...
Oracle中检查外键是否有索引的SQL脚本分享
09-10
主要介绍了Oracle中检查外键是否有索引的SQL脚本分享,本文给出了两个版本的脚本源码,一个查询所有用户,一个查询单用户,需要的朋友可以参考下
Oracle重建索引Shell脚本、SQL脚本分享
09-10
主要介绍了Oracle重建索引Shell脚本、SQL脚本分享,索引是提高数据库查询性能的有力武器,定期重建索引是很有必要的事情,需要的朋友可以参考下
oracle查询不走索引全表扫描,使用索引快速全扫描(Index FFS)避免全表扫描的若干场景-Oracle...
weixin_35458961的博客
04-11 1019
使用索引快速全扫描(Index FFS)避免全表扫描的若干场景什么使用使用Index FFS比FTS好？Oracle 8的Concept手册中介绍：1. 索引必须包含所有查询中参考到的列。2. Index FFS只能通过CBO(Index hint强制使用CBO)获得。3. Index FFS使用hint：/*+ INDEX_FFS() */。Index FFS是在7.3中引入的。在Oracle ...
oracle多表关联索引用法,多表之间的关联查询为什么没有使用上索引（在线等）...
weixin_33484711的博客
04-05 1217
SQL> create table a(aid number,name varchar(10),constraint pk_a_id primary key(aid));表已创建。SQL> create table b(bid number,name varchar(10),constraint pk_b_id primary key(bid));表已创建。SQL> create...
技术分享 | 为什么 SELECT 查询选择全表扫描，而不走索引？
ActionTech的博客
10-12 1522
作者：Charizard 爱可生服务团队成员，主要负责公司数据库运维产品问题诊断；努力在数据库和 IT 领域里摸爬滚打中。 本文来源：原创投稿 *爱可生开源社区出品，原创内容未经授权不得随意使用，转载请联系小编并注明来源。 1、基本结论 SQL的执行成本（cost）是 MySQL 优化器选择 SQL 执行计划时一个重要考量因素。当优化器认为使用索引的成本高于全表扫描的时候，优化器将会选择全表扫描，而不是使用索引。 下面通过一个实验来说明。 2、问题现象 如下结构的一张表，表中约有104w行数据： CR.
oracle表没有索引,数据库 – 为什么oracle表被索引但仍然进行全表扫描？
weixin_29096377的博客
04-08 553
如果不了解方式而不了解您的数据模型和业务,就很难给出具体的积极建议.但是这里有一些关于你的索引策略的注释以及为什么我猜测优化器没有使用你拥有的indx.在子查询中,REDLINE_MSATTRIBUTE的访问路径来自三列：> CLASS> OBJECT_ID> CHANGE_RELEASE_DATE.CLASS未编入索引.但这可能不是很有选择性. OBJECT_ID是复合索引的前...
oracle全连接索引无效,ORACLE-两表连接索引失效
weixin_39637975的博客
04-04 541
现象最近一直收到客户反馈某个报表数据查询不出来。处理过程将涉及SQL挖出来后研究未发现sql有任何异常，且未找到优化空间，F5查看执行计划发现耗费巨大，且两表索引均未生效，但把两表单独拿出来查询索引有效，所以初步认定为索引失效问题。Oracle 索引的目标是避免全表扫描，提高查询效率，但有些时候却适得其反。例如一张表中有上百万条数据，对某个字段加了索引，但是查询时性能并没有什么提高，这可能是 or...
oracle执行计划中不走索引的情况
最新发布
Melgards的博客
06-14 3756
转换成"Y"<=‘30a’ AND “Y”>=‘10a’select * from t where y not in (‘1a’,‘2a’);转换成"Y"<>‘1a’ AND “Y”<>‘2a’select * from t where y in (‘1a’,‘2a’);转换成"Y"=‘1a’ OR “Y”=‘2a’转换成"Y">=‘900a’索引列出现了函数，但是没有创建函数索引，那么就会导致索引失效。
oracle中sql不走索引问题（强制索引）
ainaoi的博客
02-23 3495
关于oracle中不走索引问题 问题：工作中明明已经写了索引，在查询中使用了索引做条件可是在解析的时候却依旧全表扫描了。 过程描述：解决问题的过程中进行了各种情况排查，均没有解决。个人理解，是oracle的数据库优化时认为查询过程中要查、读取的数据比较多，所以不值得走索引。相同的环境相同的情况却按照想法走了索引。这导致了我很难分析出问题。最终选择了保守的方式 ----> 强制执行索引 解决方案： select /*+index(tabName indexName)*/ * from table1 wh
join 索引 oracle,hash join的外表、内表是不是都不用索引？
weixin_42187487的博客
04-03 498
再来个两个都用index的：SQL> drop table test1;Table dropped.SQL> create table test1 as select * from dba_objects;Table created.SQL> create index idxtest1 on test1(object_name);Index created.SQL> set...
怎么解决oracle范围查找不走索引
04-22
针对Oracle范围查找不走索引的问题，你可以尝试以下几种解决方案： 1. 尽量避免使用范围查找：可以通过优化查询条件，尽量避免使用范围查找，如尽量使用=或IN操作符。 2. 创建合适的索引：根据实际情况创建合适的索引，包括联合索引等，优化查询效率。 3. 使用Hint强制使用索引：可以在SQL语句中使用Hint强制使用索引，如使用INDEX或者NO_INDEX。 4. 重新设计数据表：如果实在无法通过索引优化查询效率，可以重新设计数据表结构，如拆分大表等。 希望可以帮助到你解决问题，如果还有其他问题，可以继续提问。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值