在分割槽表上使用正確的索引來提高效能

問題提出：
一個三表連結，其中都是透過主鍵來連結的，而且查詢條件只有一個，而且這個列的選擇性非常高，基本上99.9的資料都不相同。其中一個表資料量在千萬，其他在百萬，這個sql一天會執行幾十萬次，佔用了大量的系統資源。[@more@]

檢視後得知千萬級的表是分割槽表，根據時間進行分割槽，10天一個分割槽。其中查詢條件上也建立了索引，不過建立的時候因為在分割槽表上建立索引，所以建立的預設是LOCAL的索引。因此導致sql執行的時候，雖然可以正確的使用索引來查詢，但是卻要跨越多個分割槽才能找到正確的值，並得到ROWID再得到表中的資料。因為開發認為正確的使用了索引，效率很高，所以在查詢條件上就只使用了建立索引的條件。
解決的辦法有兩個，一個是把LOCAL的分割槽索引改成GLOBAL的索引，二是增加一個查詢條件，因為此sql只需要查詢當天的資料，所以在分割槽的時間欄位上加上一個條件，保險期間，條件為>SYSDATE-2。
方法1操作麻煩，因為涉及到索引的刪除和重建，而此sql跑的這麼頻繁，估計夠嗆。
方法2操作簡單，只需要改改程式就ok。此方案實施後，consistent gets從1341降低到133，假如查詢跨越兩個分割槽，也比原來低很多。

總結：對於分割槽表上的索引，建立的時候還是要慎重。

後續：pub中有網友也碰見了這樣的問題，經denny2004網友的指點，發現pl/sql developer經過設定，可以看到分割槽表更詳細的執行計劃，查詢從哪個分割槽開始，到哪個分割槽結束。現把設定方法摘錄如下：

plsql的explain預設是沒有partition start和partition stop 需要自己新增，新增方法是在explain視窗中點選references，會出現 references 所示的視窗，然後你把partition start和partition stop新增進去，你可以把常用的都新增進去，預設的explain顯示的太少，新增完成後重新執行一下就可以看到了。