雖然 PostgreSQL 中的索引不需要維護或調優，但檢查實際查詢工作負載實際使用了哪些索引仍然很重要。使用 EXPLAIN 命令來檢查單個查詢的索引使用情況；本節在 第 14.1 節 中說明了其在此方面的應用。還可以收集有關正在執行的伺服器中索引使用情況的總體統計資訊，如 第 27.2 節 所述。
很難制定一個確定要建立哪些索引的通用過程。前面的章節中的示例已顯示了許多典型情況。通常需要進行大量實驗。本節的其餘部分提供了一些技巧
務必先執行 ANALYZE。此命令收集有關表中值分佈的統計資訊。此資訊對於估算查詢返回的行數至關重要，而規劃器需要這些資訊來為每個可能的查詢計劃分配真實的成本。如果沒有實際的統計資訊，將假定一些預設值，這些值幾乎可以肯定是不準確的。因此，在未執行 ANALYZE 的情況下檢查應用程式的索引使用情況是徒勞的。有關更多資訊，請參閱 第 24.1.3 節 和 第 24.1.6 節。
使用真實資料進行實驗。使用測試資料來設定索引將告訴您測試資料需要哪些索引，但僅此而已。
使用非常小的測試資料集尤其致命。雖然從 100,000 行中選擇 1,000 行可能是索引的候選，但從 100 行中選擇 1 行幾乎不會，因為這 100 行可能適合單個磁碟頁面，並且沒有計劃可以優於順序讀取 1 個磁碟頁面。
在建立測試資料時也要小心，當應用程式尚未投入生產時，這通常是不可避免的。非常相似、完全隨機或按排序順序插入的值將使統計資訊偏離真實資料將具有的分佈。
當索引未使用時，為了測試強制使用它們可能會很有用。有一些執行時引數可以關閉各種計劃型別（請參閱 第 19.7.1 節）。例如，關閉順序掃描（enable_seqscan）和巢狀迴圈連線（enable_nestloop），它們是最基本的計劃，將強制系統使用不同的計劃。如果系統仍然選擇順序掃描或巢狀迴圈連線，那麼索引未使用的原因可能更根本；例如，查詢條件不匹配索引。（前面幾節解釋了哪種查詢可以使用哪種索引。）
如果強制使用索引確實使用了索引，那麼有兩種可能性：要麼系統是正確的，使用索引確實不合適，要麼查詢計劃的成本估算沒有反映實際情況。因此，您應該對查詢進行計時，分別在有和沒有索引的情況下進行。 EXPLAIN ANALYZE 命令在這裡可能很有用。
如果事實證明成本估算錯誤，那麼同樣有兩種可能性。總成本是從每個計劃節點的每行成本乘以計劃節點的選擇性估算值計算出來的。計劃節點的估算成本可以透過執行時引數進行調整（請參閱 第 19.7.2 節）。選擇性估算不準確是由於統計資訊不足造成的。透過調整收集統計資訊的引數（請參閱 ALTER TABLE）可能可以改善這種情況。
如果您未能將成本調整得更合適，那麼您可能不得不訴諸於顯式強制使用索引。您還可以聯絡 PostgreSQL 開發人員來審查此問題。
如果您在文件中看到任何不正確、與您對特定功能的體驗不符或需要進一步澄清的內容，請使用 此表格 報告文件問題。