INDEX建立方式對SQL的影響

        我常常會聽到一些同事對自己的SQL很有信心，往往說一句：“你看，已經走索引了”。但是我們真的使用了適合我們的索引嗎？

        我抓取到一句SQL,消耗了太多的IO。

select SMIN_INFOID,NVL(MI.MONU_PROVINCE,'未知'),COUNT(*) I_RESULTNUM

FROM TBL_WAPXXX WARE,TBL_SMSXXX SMIN,TBL_MOBILEXXX MI,TBL_USERXXX USIN 

WHERE WARE_DATE > :B2 AND WARE_DATE <= :B2 + :B1 /24 

            AND WARE.WARE_UID_FK=USIN.USIN_UID_FK AND SUBSTR(USIN.USIN_PHNUM,1,7)=MI.MONU_PHONENUM(+) 

            AND WARE_WRUIID_FK=SMIN.SMIN_INFOID GROUP BY SMIN_INFOID ,MI.MONU_PROVINCE

     因為TBL_WAPXXX資料量比較大,而造成該SQL執行緩慢並且IO消耗高。看看它的SQL執行計劃和成本估算(如下圖)

        注意畫框INDEX(為TBL_WAPXXX的相關索引)，雖然走了索引，但是成本和cardnility都很高。檢查這個索引發現其實BLEVEL只有2。而再仔細檢視SQL並詢問實現的功能，其實索引的欄位為DATE型別,該SQL只是檢查最近幾個小時的資訊變化.

        在WHERE條件中(WARE_DATE > :B2)因為是範圍查詢,索引使用了(rang scan)，加之該表資料量眾多(千萬級別)，直接影響了SQL執行效能。

         但是透過檢查發現，這個索引就是直接建立的B-TREE索引。而我注意到其實該SQL檢查的就是最近一個或幾個小時的資料，終於可以找到一些問題所在了。INDEX建立時預設情況下，索引的欄位採用升序(asc)建立，而這種方法顯然是不適合當前這個SQL的，我們可以透過建立基於降序的索引來適應實際的需求。

SQL> create index IDX_WARE_DATE1 on TBL_WAPXXXX(WARE_DATE desc)

    2        tablespace USERTBS;

        再來檢查執行的SQL計劃和預算成本:

        執行成本大幅降低。INDEX的建立時索引欄位排序的方式其實對特定SQL影響還是很大的。尤其是一些歷史流水錶，在某些情況下只是查詢近期的資料時，就顯得尤為重要了。

        注：文中的SQL因為某些問題，我做了適當的處理，在顯示的執行計劃圖中也是處理過的，所以會出現表名不十分匹配的問題，請大家見諒。

        PS:

         最近總是很忙，忙的只有在睡覺前才有時間寫點東西。但是實在太累，總是無法好好的寫。真的要好好堅持堅持呀 -:)，否則年初的目標就很難完成了。

©著作權歸作者所有：來自51CTO部落格作者Larry.Yue的原創作品，如需轉載，請註明出處，否則將追究法律責任

ORACLESQL資料庫ORACLE足跡