| |
2、WHERE后面的條件順序影響
WHERE子句后面的條件順序?qū)Υ髷?shù)據(jù)量表的查詢會產(chǎn)生直接的影響。如：
Select * from zl_yhjbqk where dy_dj = '1KV以下' and xh_bz=1
Select * from zl_yhjbqk where xh_bz=1 and dy_dj = '1KV以下'
以上兩個SQL中dy_dj（電壓等級）及xh_bz（銷戶標(biāo)志）兩個字段都沒進(jìn)行索引，所以執(zhí)行的時候都是全表掃描，第一條SQL的dy_dj = '1KV以下'條件在記錄集內(nèi)比率為99%，而xh_bz=1的比率只為0.5%，在進(jìn)行第一條SQL的時候99%條記錄都進(jìn)行dy_dj及xh_bz的比較，而在進(jìn)行第二條SQL的時候0.5%條記錄都進(jìn)行dy_dj及xh_bz的比較，以此可以得出第二條SQL的CPU占用率明顯比第一條低。
3、查詢表順序的影響
在FROM后面的表中的列表順序會對SQL執(zhí)行性能影響，在沒有索引及ORACLE沒有對表進(jìn)行統(tǒng)計分析的情況下，ORACLE會按表出現(xiàn)的順序進(jìn)行鏈接，由此可見表的順序不對時會產(chǎn)生十分耗服物器資源的數(shù)據(jù)交叉。（注：如果對表進(jìn)行了統(tǒng)計分析，ORACLE會自動先進(jìn)小表的鏈接，再進(jìn)行大表的鏈接）
三、SQL語句索引的利用
1、操作符優(yōu)化（同上）
2、對條件字段的一些優(yōu)化
采用函數(shù)處理的字段不能利用索引，如：
substr(hbs_bh,1,4)=’5400’，優(yōu)化處理：hbs_bh like ‘5400%’
trunc(sk_rq)=trunc(sysdate)， 優(yōu)化處理：sk_rq>=trunc(sysdate) and sk_rq
進(jìn)行了顯式或隱式的運(yùn)算的字段不能進(jìn)行索引，如：ss_df+20>50，優(yōu)化處理：ss_df>30
‘X’ hbs_bh>’X5400021452’，優(yōu)化處理：hbs_bh>’5400021542’
sk_rq+5=sysdate，優(yōu)化處理：sk_rq=sysdate-5
hbs_bh=5401002554，優(yōu)化處理：hbs_bh=’ 5401002554’，注：此條件對hbs_bh 進(jìn)行隱式的to_number轉(zhuǎn)換，因?yàn)閔bs_bh字段是字符型。
條件內(nèi)包括了多個本表的字段運(yùn)算時不能進(jìn)行索引，如：ys_df>cx_df，無法進(jìn)行優(yōu)化
qc_bh kh_bh=’5400250000’，優(yōu)化處理：qc_bh=’5400’ and kh_bh=’250000’
四、其他
ORACLE的提示功能是比較強(qiáng)的功能，也是比較復(fù)雜的應(yīng)用，并且提示只是給ORACLE執(zhí)行的一個建議，有時如果出于成本方面的考慮ORACLE也可能不會按提示進(jìn)行。根據(jù)實(shí)踐應(yīng)用，一般不建議開發(fā)人員應(yīng)用ORACLE提示，因?yàn)楦鱾�數(shù)據(jù)庫及服務(wù)器性能情況不一樣，很可能一個地方性能提升了，但另一個地方卻下降了，ORACLE在SQL執(zhí)行分析方面已經(jīng)比較成熟，如果分析執(zhí)行的路徑不對首先應(yīng)在數(shù)據(jù)庫結(jié)構(gòu)（主要是索引）、服務(wù)器當(dāng)前性能（共享內(nèi)存、磁盤文件碎片）、數(shù)據(jù)庫對象（表、索引）統(tǒng)計信息是否正確這幾方面分析。
|
| 【收藏】【打印】【進(jìn)入論壇】 |
|
|
|
|
| |
|
|
|
