另類SQL優化

http://www.itpub.net/428148.html

我最近遇到一個sql的優化問題，由於受到許多限制，想了許久終於找到解決方法：
sql語句如下：

SELECT COUNT (*) FROM kc24
WHERE aae040 >= :b1
AND aae040 <= :b2
AND akb020 LIKE :b3 AND akc021 LIKE :b4 AND aka130 LIKE :b5
AND aab001 LIKE :b6 AND SUBSTR (aae072, 1, 1) != '_'
AND akc501 = :b7

KC24表上在akb020加上其他兩個欄位（包括aae072)作為主鍵索引，aae040為日期型
變數，並建立了索引。由於akb020這個欄位非常特殊，其所有的值都是一樣的。表大小
120M，記錄數為703XXX，主鍵索引PK_KC24為29M（壓縮了欄位1），i_kc24_aae040索引
為14M.我重新分析了表，我發現執行計劃還是使用PK_KC24索引，這樣實際上還不如選擇
全表掃描。
我又分析了表，加入直方圖的統計，執行計劃依舊。最終我發現optimizer_index_cost_adj，
optimizer_index_caching設定影響了執行計劃。不過很奇怪的是如果沒有這一行
AND SUBSTR (aae072, 1, 1) != '_'，執行計劃就會使用aae040的索引。

optimezer*的引數我不能再修改，因為這個引數已經經過測試，已經設定在最佳模式。
使用的資料庫是oracle8i的標準版，程式是第3方開發的，又不能修改程式碼，標準版又不支
持大綱（我個人並不喜歡使用這種方式），到這裡優化陷入困境。。。。

後來我想如果能夠修改統計資訊，人為的加大PK_KC24索引的統計大小，就可以改變執行計劃，
仔細看看書，dbms_stats可以修改統計資訊，不過修改統計資訊，一定要檢查相關kc24的sql語句，
否則可能影響別的sql語句執行計劃。

EXECUTE SYS.DBMS_STATS.set_index_stats (OWNNAME=>'TEST', INDNAME=>'PK_KC24', numlblks=> 8000);

在檢查執行計劃，發現能使用aae040索引，並且在檢查相關的kc24的sql語句，沒有問題，整個優化完成。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/267265/viewspace-82798/，如需轉載，請註明出處，否則將追究法律責任。