| PostgreSQL 7.4 文檔 | ||||
|---|---|---|---|---|
| Prev | Fast Backward | Chapter 11. 索引 | Fast Forward | Next |
盡管在 PostgreSQL 裡的索引並不需要維護和調節, 但是檢查一下哪些索引是在實際查詢工作中得到使用的仍然是非常重要的. 檢查索引的使用是通過 EXPLAIN 命令進行的; 為此目地做的應用在 Section 13.1 裡演示. 我們也可以在一個運行的服務器上收集有關索引使用的全部可能性, 就想在 Section 23.2 裡描述的那樣。
歸納一個判斷需要設置哪些索引的通用過程是很難的. 在前面的章節中已經列出了許多典型的例子. 在大多數情況下我們都需要許多試驗.本節的剩餘部分就是給出一些這方面的竅門.
總是先運行 ANALYZE. 這條命令收集關于表中數值分布的統計.猜測一個查詢返回的行數需要這個信息, 而規劃器需要這個行數以便給每個可能的查詢規劃賦予真實開銷值. 如果缺乏任何真實的統計信息,那麼就會假設一些缺省數值, 那肯定是不準確的.因此,如果還沒有運行 ANALYZE 就檢查一個應用的索引使用狀況,那實際上就是一次失敗的檢查.
使用真實的數據做實驗.用測試數據設置索引將告訴你在測試數據中需要什麼索引,而不是在所有數據中.
最要命的是用按比例縮小的數據集.如果從 100000 行中選 1000 行是使用索引的好時機, 那麼從 100 行中選 1 行很難說也需要索引, 因為 100 行很可能是裝在一個磁盤頁裡面的, 因此沒有任何查詢規劃能比通過順序訪問抓取一個磁盤頁面更有效.
做測試數據的時候也要小心 -- 如果應用還不能在生產環境中使用, 那麼這也是不可避免的.那些非常相似的數據,完全隨機的數據, 或者按照排序順序插入的數據會令統計信息偏離實際數據應該具有的特征.
如果索引沒有得到使用,那麼在測試中強制它的使用也許有些價值. 有一些運行時參數可以關閉各種各樣的查詢規劃(在 Section 16.4 中描述). 比如,關閉順序掃描(enable_seqscan)和嵌套循環連接(enable_nestloop)將強迫系統使用不同的規劃。 (這些規劃是最基本的規劃。)如果系統仍然選擇順序掃描或者嵌套循環聯接, 那麼在為何索引沒有得到使用的問題中可能有更基本的問題, 比如,查詢條件和索引不匹配等.(我們在前面的章節中介紹了什麼樣的查詢可以使用什麼樣的索引.)
如果強制索引用法的確使用了索引,那麼就有兩種可能︰ 要麼是系統選擇是正確的︰使用索引實際上並不合適, 要麼是查詢計劃的開銷計算並不反映現實情況. 這樣你就應該對使用和不使用索引的查詢進行計時.這個時候 EXPLAIN ANALYZE 命令就很有用了.
如果實際情況說明開銷計算是錯誤的,那麼仍然有兩種可能. 總開銷是從每行的每個規劃節點乘以每個規劃節點的選擇性估計的開銷計算出來的。 規劃節點的開銷可以用一些運行時參數進行調節(在 Section 16.4 中描述)。 不準確的選擇性估計是因為統計信息不夠充分。 我們可以通過調節統計收集參數(參閱 ALTER TABLE)提高選擇性估計的精確度。
如果你沒能通過將開銷調整得更準確實現索引的使用,那麼你可能不得不 求助于明確地強制索引使用.而且也許與 PostgreSQL 開發人員聯系並且討論你的情況也是值得考慮的.