查看oracle自动优化,使用索引查询更快，优化器为何不能自动识别
本帖最后由 〇〇 于 2015-12-24 12:17 編輯
有如下查詢，不加hint時，優(yōu)化器自己選擇的執(zhí)行計劃是走全表掃描，花費(fèi)時間很長，
但加hint強(qiáng)制讓大表走skip index時間很短，根據(jù)傳統(tǒng)的理解，引導(dǎo)列上重復(fù)出現(xiàn)的值越少
走skip index的可能越大.但本查詢中引導(dǎo)列的重復(fù)值也不多，且強(qiáng)制使用skip index后花費(fèi)的時間
明顯減少，在不加hint時，優(yōu)化器為什么不能自己判斷出走skip index后更快的執(zhí)行計劃呢?
哪位大俠能給個skipindex cost計算的公式？謝謝
本查詢結(jié)構(gòu)是一個有30條數(shù)據(jù)的小表，和一個4百萬數(shù)據(jù)的大表關(guān)聯(lián)，大表上有主鍵索引
主鍵索引中有兩列 如(YMD，SERL_NO),YMD列就是前導(dǎo)列。具體查詢和執(zhí)行計劃如下
1使用索引時
SQL_ID??4nr6cv01fxb4s, child number 0
-------------------------------------
SELECT /*+ INDEX_SS(T1 PK_RW_BI_FT_LT) */
T2.SERL_NO
,T1.SI_YMD
,T1.ST_YMD
,T1.ST2_YMD
,T1.SO_YMD
,T1.ACTU_DT
FROM MCS_HQ_READ.RW_BI_FT_LT_BAK T1
,MCS_HQ_READ.UP_LOAD_SERL10 T2
WHERE T1.SERL_NO = T2.SERL_NO
Plan hash value: 2981316369
----------------------------------------------------------------------------------------------------------
| Id??| Operation? ?? ?? ?? ?? ?? ???| Name? ?? ?? ?? ?| Starts | E-Rows | A-Rows |? ?A-Time? ?| Buffers |
----------------------------------------------------------------------------------------------------------
|? ?0 | SELECT STATEMENT? ?? ?? ?? ? |? ?? ?? ?? ?? ???|? ?? ?1 |? ?? ???|? ???29 |00:00:00.03 |? ? 6060 |
|? ?1 |??NESTED LOOPS? ?? ?? ?? ?? ? |? ?? ?? ?? ?? ???|? ?? ?1 |? ???10 |? ???29 |00:00:00.03 |? ? 6060 |
|? ?2 |? ?TABLE ACCESS FULL? ?? ?? ? | UP_LOAD_SERL10??|? ?? ?1 |? ???29 |? ???29 |00:00:00.01 |? ?? ? 2 |
|? ?3 |? ?TABLE ACCESS BY INDEX ROWID| RW_BI_FT_LT_BAK |? ???29 |? ?? ?1 |? ???29 |00:00:00.03 |? ? 6058 |
|*??4 |? ? INDEX SKIP SCAN? ?? ?? ???| PK_RW_BI_FT_LT??|? ???29 |? ?? ?1 |? ???29 |00:00:00.03 |? ? 6032 |
----------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
4 - access("T1"."SERL_NO"="T2"."SERL_NO")
filter("T1"."SERL_NO"="T2"."SERL_NO")
2全表掃描時
SQL_ID??c3shr653mx487, child number 0
-------------------------------------
SELECT? ?? ???T2.SERL_NO
,T1.SI_YMD
,T1.ST_YMD
,T1.ST2_YMD
,T1.SO_YMD
,T1.ACTU_DT
FROM MCS_HQ_READ.RW_BI_FT_LT_BAK T1
,MCS_HQ_READ.UP_LOAD_SERL10 T2
WHERE T1.SERL_NO = T2.SERL_NO
Plan hash value: 1553165350
---------------------------------------------------------------------------------------------------------
| Id??| Operation? ?? ?? ? | Name? ?? ?? ?? ?| Starts | E-Rows | A-Rows |? ?A-Time? ?| Buffers | Reads??|
---------------------------------------------------------------------------------------------------------
|? ?0 | SELECT STATEMENT? ?|? ?? ?? ?? ?? ???|? ?? ?1 |? ?? ???|? ???29 |00:00:06.16 |? ???105K|? ? 105K|
|*??1 |??HASH JOIN? ?? ?? ?|? ?? ?? ?? ?? ???|? ?? ?1 |? ???10 |? ???29 |00:00:06.16 |? ???105K|? ? 105K|
|? ?2 |? ?TABLE ACCESS FULL| UP_LOAD_SERL10??|? ?? ?1 |? ???29 |? ???29 |00:00:00.01 |? ?? ? 2 |? ?? ?0 |
|? ?3 |? ?TABLE ACCESS FULL| RW_BI_FT_LT_BAK |? ?? ?1 |? ?1379K|? ?3999K|00:00:03.96 |? ???105K|? ? 105K|
---------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - access("T1"."SERL_NO"="T2"."SERL_NO")
具體統(tǒng)計信息參考
索引統(tǒng)計
INDEX_NAME? ?? ???INDEX_TYPE? ?? ???BLEVEL? ?? ???LEAF_BLOCKS? ?? ???DISTINCT_KEYS? ?? ???AVG_LEAF_BLOCKS_PER_KEY? ?? ???AVG_DATA_BLOCKS_PER_KEY? ?? ???CLUSTERING_FACTOR? ?? ???NUM_ROWS
PK_RW_BI_FT_LT? ?? ???NORMAL? ?? ???2? ?? ???24675? ?? ???3879361? ?? ???1? ?? ???1? ?? ???3819111? ?? ???3879361
表統(tǒng)計
TABLE_NAME? ?? ???NUM_ROWS? ?? ???BLOCKS? ?? ???EMPTY_BLOCKS? ?? ???AVG_SPACE? ?? ???CHAIN_CNT? ?? ???AVG_ROW_LEN? ?? ???SAMPLE_SIZE? ?? ???PARTITIONED
RW_BI_FT_LT_BAK? ?? ???3999999? ?? ???105977? ?? ???0? ?? ???0? ?? ???0? ?? ???190? ?? ???3999999? ?? ???NO
前導(dǎo)列YMD統(tǒng)計
COLUMN_NAME? ?? ???NUM_DISTINCT? ?? ???LOW_VALUE? ?? ???HIGH_VALUE? ?? ???DENSITY? ?? ???NUM_NULLS? ?? ???NUM_BUCKETS? ?? ???SAMPLE_SIZE? ?? ???HISTOGRAM? ?? ???AVG_COL_LEN
YMD? ?? ???61? ?? ?? ?3230313431313030? ?? ?? ?3230313431323330? ?? ?? ?0.016393443? ?? ???0? ?? ???1? ?? ???3999999? ?? ???NONE? ?? ???9
總結(jié)
以上是生活随笔為你收集整理的查看oracle自动优化,使用索引查询更快，优化器为何不能自动识别的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： jert oracle 统计说明,Ora
- 下一篇： linux 更改父进程名称,[Linux