PostgresSQL-檢查索引的使用

儘管在 PostgreSQL 裏的索引並不須要維護和調節， 可是檢查一下哪些索引是在實際查詢工做中獲得使用的仍然是很是重要的。 檢查索引的使用是經過 EXPLAIN 命令進行的； 爲此目的作的應用在 Section 13.1 裏演示。 咱們也能夠在一個運行的服務器上收集有關索引使用的所有可能性， 就想在 Section 24.2 裏描述的那樣。

概括一個判斷須要設置哪些索引的通用過程是很難的。 在前面的章節中已經列出了許多典型的例子。 在大多數狀況下咱們都須要許多試驗。本節的剩餘部分就是給出一些這方面的竅門。

• 老是先運行 ANALYZE。 這條命令收集關於表中數值分佈的統計。猜想一個查詢返回的行數須要這個信息， 而規劃器須要這個行數以便給每一個可能的查詢規劃賦予真實開銷值。 若是缺少任何真實的統計信息，那麼就會假設一些缺省數值， 那確定是不許確的。所以，若是尚未運行 ANALYZE 就檢查一個應用的索引使用情況，那實際上就是一次失敗的檢查。

• 使用真實的數據作實驗。用測試數據設置索引將告訴你在測試數據中須要什麼索引，而不是在全部數據中。

  最要命的是用很小的數據集。若是從 100000 行中選 1000 行是使用索引的好時機， 那麼從 100 行中選 1 行很難說也須要索引， 由於 100 行極可能是裝在一個磁盤頁裏面的， 所以沒有任何查詢規劃能比經過順序訪問抓取一個磁盤頁面更有效。

  作測試數據的時候也要當心 -- 若是應用還不能在生產環境中使用， 那麼這也是不可避免的。那些很是類似的數據，徹底隨機的數據， 或者按照排序順序插入的數據會令統計信息偏離實際數據應該具備的特徵。

• 若是索引沒有獲得使用，那麼在測試中強制它的使用也許有些價值。 有一些運行時參數能夠關閉各類各樣的查詢規劃（在 Section 17.6.1 中描述）。 好比，關閉順序掃描（enable_seqscan）和嵌套循環鏈接（enable_nestloop）將強迫系統使用不一樣的規劃。 （這些規劃是最基本的規劃。）若是系統仍然選擇順序掃描或者嵌套循環聯接， 那麼在爲什麼索引沒有獲得使用的問題中可能有更基本的問題， 好比，查詢條件和索引不匹配等。（咱們在前面的章節中介紹了什麼樣的查詢可使用什麼樣的索引。）

• 若是強制索引用法的確使用了索引，那麼就有兩種可能∶ 要麼是系統選擇是正確的∶使用索引實際上並不合適， 要麼是查詢計劃的開銷計算並不反映現實狀況。 這樣你就應該對使用和不使用索引的查詢進行計時。這個時候 EXPLAIN ANALYZE 命令就頗有用了。

• 若是實際狀況說明開銷計算是錯誤的，那麼仍然有兩種可能。 總開銷是從每行的每一個規劃節點乘以每一個規劃節點的選擇性估計的開銷計算出來的。 規劃節點的開銷能夠用一些運行時參數進行調節（在 Section 17.6.2 中描述）。 不許確的選擇性估計是由於統計信息不夠充分。 咱們能夠經過調節統計收集參數（參閱 ALTER TABLE）提升選擇性估計的精確度。

  若是你沒能經過將開銷調整得更準確實現索引的使用，那麼你可能不得不 求助於明確地強制索引使用。並且也許與 PostgreSQL 開發人員聯繫而且討論你的狀況也是值得考慮的。