Oracle优化选择错误的索引而不是表全扫描

2020-09-21 23:23发布

点击此处---> 群内免费提供SAP练习系统(在群公告中)加入QQ群:457200227(SAP S4 HANA技术交流) 群内免费提供SAP练习系统(在群公告中)当我们更换工作中心时,它非常慢。...

         点击此处--->   EasySAP.com群内免费提供SAP练习系统(在群公告中)

加入QQ群:457200227(SAP S4 HANA技术交流) 群内免费提供SAP练习系统(在群公告中)


当我们更换工作中心时,它非常慢。 这需要超过10分钟的时间并超时。 OSS注释415031讨论了AFRU表上的索引。 AFRU本身的查询大约需要9分钟。 AFRU表大约有500万行。

我有几个问题,当我查看我的解释语句时,它正在选择一个没有" WHERE"字段的自定义索引。 我很好奇,为什么oracle优化器不选择表扫描? 我希望对AFRU表进行全表扫描(具有超过500万行的速度比使用没有适当字段的索引还要快)。 是否可能由于选择了错误的索引而导致延迟?

我试图将HINT放入自定义程序中,看看是否可以强制执行TABLE FULL SCAN,它的速度似乎更快。

我很困惑。 这是一个一次性的方案,我当时认为表扫描可能不会那么糟糕。 但是优化器从不选择表扫描。 我想避免为此类异常情况创建新索引,但是超时不是一种选择。

统计

解析时间戳:20180208 17:57:45

系统:RQ1

SQL_ID 18fyjygmadgtd,子编号1

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

SELECT/* + FIRST_ROWS(1)*/*来自" AFRU",而" MANDT" =:A0 AND

" ARBID" =:A1和ROWNUM <=:A2

计划哈希值:4214817510

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

| ID | 操作| 姓名| 行| 字节数| 费用(%CPU)| 时间|

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

| 0 | 选择声明| | | | 256(100)| |

| * 1 | COUNT STOPKEY | | | | | |

| * 2 | 表访问按索引行分批| AFRU | 1 | 585 | 256(0)| 00:00:01 |

| * 3 | 索引范围扫描| AFRU〜Z01 | | | 8(0)| 00:00:01 |

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

查询块名称/对象别名(由操作ID标识):

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

1-SEL $ 1

2-SEL $ 1/AFRU @ SEL $ 1

3-SEL $ 1/AFRU @ SEL $ 1

谓词信息(由操作ID标识):

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

1-过滤器(ROWNUM <=:A2)

2-filter(" ARBID" =:A1)

3-访问(" MANDT" =:A0)

列投影信息(由操作ID标识):

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

1-" MANDT" [VARCHAR2,9]," AFRU"。" RUECK" [VARCHAR2,30]," AFRU"。" RMZHL" [VARCHAR2,24],

" AFRU"。" GRUND" [VARCHAR2,12]," AFRU"。" PERNR" [VARCHAR2,24]," AFRU"。" ISDD" [VARCHAR2,24],

" AFRU"。" ISDZ" [VARCHAR2,18]," AFRU"。" IERD" [VARCHAR2,24]," AFRU"。" IERZ" [VARCHAR2,18],

" AFRU"。" ISBD" [VARCHAR2,24]," AFRU"。" ISBZ" [VARCHAR2,18]," AFRU"。" IEBD" [VARCHAR2,24],

" AFRU"。" IEBZ" [VARCHAR2,18]," AFRU"。" ISAD" [VARCHAR2,24]," AFRU"。" ISAZ" [VARCHAR2,18],

" AFRU"。" KAPTPROG" [VARCHAR2,12]," AFRU"。" OBMAT" [VARCHAR2,54],

" AFRU"。" OBCHA" [VARCHAR2,30]," AFRU"。" LICHA" [VARCHAR2,45]," AFRU"。" MYEAR" [VARCHAR2,12],

" AFRU"。" ME_SFCID" [VARCHAR2,180]," AFRU"。" ROLE_ID"

3-" AFRU" .ROWID [ROWID,10]," MANDT" [VARCHAR2,9]," AFRU"。" CATSBELNR" [VARCHAR2,30],

" AFRU"。" STZHL" [VARCHAR2,24]

表AFRU

最后统计日期02/06/2018 23:35
分析方法充足5,775,114行
行数5,775,114
已分配块数490,556
空数 块0
平均空间0
链数0
平均行长585
分区NO
并行度1


非唯一索引AFRU〜Z01

列名#Distinct

MANDT 2
CATSBELNR 964,686
STZHL 11,121

非唯一索引AFRU〜Z02

列名#Distinct

佛得角5,792
WERKS 104


唯一索引AFRU〜0

列名#Distinct

MANDT 2
RUECK 3,146,901
RMZHL 80,338

列统计

列#Distinct U #BU AVGL数据类型Len

ABARB 101 1 4 VARCHAR2 9
AENAM 632 1 3 VARCHAR2 36
ANZMA 1 1 2 NUMBER 22
APLFL 2 1 5 VARCHAR2 18
APLZL 541 1 9 VARCHAR2 24
> ARBID 1146 1 9 VARCHAR2 24
AUERU 3 1 2 VARCHAR2 3
AUFNR 2167229 1 13 VARCHAR2 36
AUFPL 2203561 1 11 VARCHAR2 30
AUSOR 2 1 2 VARCHAR2 3
BELNR_IST 1 1 2 VARCHAR2 30
BELNR_UMB 1 1 2 VARCHAR2 30 BEMOT 2 1 3 VARCHAR2 6
BUDAT 5792 1 9 VARCHAR2 24
CANUM 1 1 5 VARCHAR2 12 12
CATSBELNR 964686 1 4 VARCHAR2 30
STZHL 11121 1 9 VARCHAR2 24

11条回答
哎,真难
2020-09-21 23:51 .采纳回答

已经有一些出色的输入,我也同意您的数据和统计数据存在某些特殊性,这导致Oracle选择索引。

我看到您的统计数据是最近的,因此它们可能没有错。 但是我有另一种理论可以提供:ARBID字段通常是填充的还是很多为空? 归结为数据分发,有时统计可能会误解数据分发。 如果唯一性是100%,则应选择全表扫描。 但是,如果90%的行为空,或者您有多次重复出现的值(通常是状态字段),那么唯一性就很低,从统计学上讲,优化程序可能会决定我们很可能在非 索引字段很容易,因为大多数值都相似。 在几乎为空的列中搜索值时,这尤其是个问题。

此外,仅出于兴趣考虑,请查看"最多1行"的行为是否与"选择单个"不同。 在进行此操作的同时,还请尝试选择SELECT而不加任何限制和变化...高达10/100/1000 ROWS。

一周热门 更多>