索引未使用Postgres

跟蹤索引並分析索引添加的表，我們遇到一些情況：我們的一些表有索引，但是當我在索引字段上使用where子句執行查詢時，你的idx_scan字段各自。同樣的relname和schemaname，所以我沒有錯。索引未使用Postgres

測試更多，我刪除並重新創建表，之後該查詢返回的佔idx_scan。

與其他表一樣，我們執行了一些帶索引的查詢，但沒有對idx_scan字段進行帳戶處理，僅在seq_scan中，即使我在與索引相同的表中創建另一個字段，此新字段也不計算idx_scan 。

這些表格有什麼問題？我們做錯了什麼？只有當我創建了一個新的表，其中包含idx_scan中的索引時，只是在舊錶中有錯誤。我們有時會用這個數據庫做遷移，也許這可能是問題所在？發生在本地主機和服務器在線。

另一個我們看到的事件，一些索引被記錄，idx_scan> 0，並且當執行query select時，不會再次增加idx_scan，這個數字是固定的，只是增加seq_scan。我相信這些問題可以相關。

我很欣賞一些幫助，這是一個很大的謎竄來竄去我們的數據庫，而且不知道這個問題可能是什麼。

來源

2012-08-31 Pedro Eugênio

Postgres的可能不會使用索引。 –

最常見的原因是，在對錶進行大量插入/刪除操作後，分析尚未運行。出於這個原因，我不得不在數據構建過程中明確地運行分析。 –

我同意你的意見，邁克，說出你的意思。而且我對盧卡斯所說的並不是很瞭解，包括我的表格後需要執行分析或刪除很多寄存器，是嗎？到idx_scan開始考慮 –

一些建議（以及添加到您的問題）。

首先是索引掃描並不總是有利於順序掃描。例如，如果您的表格很小或者規劃者估計需要獲取大多數頁面，則索引掃描將被省略以支持順序掃描。

請記住：沒有計劃會跳過從磁盤檢索單個頁面並依次運行它。

同樣，如果你需要檢索，說，一個關係的網頁，做一個索引掃描的50％將要交易稍差磁盤/ IO總爲更大量的隨機磁盤/ IO。如果你使用SSD的話，這可能是一個勝利，但肯定不是傳統的硬盤。畢竟你並不是真的想等待盤片轉向。如果您使用的是SSD，則可以相應地調整規劃器設置。

所以索引與順序掃描不是故事的結尾。現在的問題是有多少行被檢索，表格有多大，被檢索多大比例的磁盤頁等

如果真的是撿個不錯的計劃（而不是你沒有考慮好計劃！）那麼問題就變成了原因。有些方法可以設定統計目標，但這些可能並不真正有用。

最後，在您可能喜歡的情況下，規劃師確實無法選擇索引。例如，假設我有一個1000萬行表，記錄跨度5年（平均每年約有200萬行）。我想得到明顯的歲月。我不能用標準查詢和索引來做到這一點，但是我可以構建一個WITH RECURSIVE CTE來基本上每年執行一次相同的查詢，並且會使用索引。當然你最好在這種情況下有一個索引，或者WITH RECURSIVE會爲每一年做一個順序掃描，這當然不是你想要的！

tl; dr：這很複雜。在做出結論之前，你要確保這是一個非常糟糕的計劃，然後如果這是一個糟糕的計劃，請根據您的配置查看您可以做些什麼。如果它認爲連續掃描最終會更快

來源

2012-09-01 01:44:37

索引未使用Postgres

回答

相關問題