INDEX建立方式對SQL的影響

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

我抓取到一句sql,消耗了太多的io。

select smin_infoid,nvl(mi.monu_province,

'未知'),

count

(*) i_resultnum

from tbl_wap*** ware,tbl_sms*** smin,tbl_mobile*** mi,tbl_user*** 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_wap***資料量比較大,而造成該sql執行緩慢並且io消耗高。看看它的sql執行計畫和成本估算(如下圖)

注意畫框index(為tbl_wap***的相關索引)，雖然走了索引，但是成本和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_wap***x(ware_date

desc)

2 tablespace usertbs;

再來檢查執行的sql計畫和預算成本:

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

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