11.8. 檢查索引的使用

儘管在 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 開發人員聯繫並且討論您的情況也是值得考慮的。