Oracle 通過複合索引提高查詢性能的一個真實客戶例子

這是一個真實的應用,客戶報了一個EBS的performance bug, 在Invoice form裏,選擇了一個客戶後,再打開賬單地址(location)的LOV,花了20分鐘出來了3條地址數據.


分析了客戶上傳的trc文件(轉成prf),發現查詢是類似這樣的:


select t1.customer_id, t1.customer_name, t2.location
......
from customer t1, customer_site t2
where t1.customer_number = :P_number
and t1.site_id = t2.customer_site_id
and t2.location like '%%'


在prf中顯示,對customer_site表是 INDEX SCAN, 返回了800多萬條數據, 再查看了customer_site表定義,發現對存在這樣一個index: INDEX_N4 on (location), 這是一個單一索引,感覺使用這個單一索引和全表掃描並沒有太大區別,因爲是先查找出了800多萬條數據,然後再進行外連接,所以效率這麼低.


於是想到了用複合索引,因爲查詢條件中涉及到了兩個列(customer_site_id和location),所以把customer_site_id也加入到索引INDEX_N4中,於是索引爲這樣: 
create index INDEX_N4 on customer_site(location,customer_site_id)
然後再讓客戶試了一下,查詢時間減少到了幾秒鐘.


在建立這個複合索引的時候,對於這個順序我糾結了一陣子,索引列的順序對查詢的性能還是有影響的,所以這兩列的順序也要確定一下,網上搜索了一下發現有這樣的約定:
1. 選擇性最大的列做複合索引的前導列.
2. 查詢時where的列能包含索引列.
這兩列都在where查詢語句中,所以添加customer_site_id到索引中是正確的,而在這裏location的選擇性比customer_site_id大,所以location放前面.在比較確定做這樣的改變能解決客戶問題後,我把這個解決方案給了客戶,事實上也確實解決了客戶的問題.