我的Postgres數據庫沒有使用我的索引;我解決了它，但不明白修復，任何人都可以解釋發生了什麼？

我的相關部分的數據庫模式是有一個名爲User的表，它有一個布爾型字段Admin。該字段管理員有一個索引。我的Postgres數據庫沒有使用我的索引;我解決了它，但不明白修復，任何人都可以解釋發生了什麼？

將我的完整生產數據庫恢復到我的開發機器之前的一天，然後對數據庫做了很小的修改，所以它們應該非常相似。

當我跑我的開發機器上運行以下命令，我得到了預期的結果：

EXPLAIN SELECT * FROM user WHERE admin IS TRUE; 

Index Scan using index_user_on_admin on user (cost=0.00..9.14 rows=165 width=3658) 
Index Cond: (admin = true) 
Filter: (admin IS TRUE)

然而，當我跑我的生產機器上完全相同的命令，我得到這個：

Seq Scan on user (cost=0.00..620794.93 rows=4966489 width=3871) 
Filter: (admin IS TRUE)

因此，不是使用完全匹配查詢的確切索引，而是使用了近500萬行的順序掃描！

然後我試圖運行EXPLAIN ANALYZE SELECT * FROM user WHERE admin IS TRUE;，希望ANALYZE會使Postgres實現500萬行的順序掃描不如使用索引，但這並沒有改變任何東西。

我也嘗試運行REINDEX INDEX index_user_on_admin以防索引損壞，沒有任何好處。

最後，我打電話給VACUUM ANALYZE user，並在短期內解決了這個問題。

我對真空的主要理解是，它被用來回收浪費的空間。可能發生的事情會導致我的索引變得糟糕，爲什麼真空會修復它？

來源

2012-09-01 William Jones

這是最有可能的ANALYZE，幫助，通過更新所使用的規劃師來確定數據統計什麼是運行最好的辦法一個問題。 VACUUM ANALYZE只是按順序運行這兩個命令，第一個是VACUUM，第二個是ANALYZE，但ANALYZE本身可能足以提供幫助。
ANALYZE選項到EXPLAIN與ANALYZE命令完全沒有關係。它只是使Postgres運行查詢並報告實際運行時間，以便可以將它們與規劃器預測進行比較（EXPLAIN，而不是ANALYZE僅顯示查詢計劃以及規劃者認爲它會花費什麼，但實際上並沒有運行查詢）。所以EXPLAIN ANALYZE沒有幫助，因爲它沒有更新統計信息。 ANALYZE和EXPLAIN ANALYZE是兩個完全不同的動作，恰好碰巧使用同一個單詞。

來源

2012-09-01 22:02:59

PostgreSQL保留了許多有關表條件，索引條件，數據等的高級統計信息......有時候這可能會不同步。運行VACUUM將糾正該問題。

很有可能您在開發時從頭開始重新加載表格時，它具有相同的效果。

看看這個：

http://www.postgresql.org/docs/current/static/maintenance.html#VACUUM-FOR-STATISTICS

來源

2012-09-01 20:33:39 gahooa

感謝您的鏈接，關於爲什麼我的電話分析查詢不足的任何想法？ –

實際上'ANALYZE'糾正了這個問題。 '真空分析'碰巧做到了這兩點。另外注意，'EXPLAIN ANALYSE'不會對EXPLAIN所做的任何表進行任何分析。它所做的是運行查詢並與成本估算進行比較。 –

一個partial index似乎是您的問題很好的解決方案：

CREATE INDEX admin_users_ix ON users (admin) 
    WHERE admin IS TRUE;;

已經沒有意義，指數在相同的領域很多元組。

來源

2012-09-01 22:30:44 danihp

只有一件事。如果規劃人員不使用其他索引，則在這種情況下不會使用這種情況。不過我注意到，部分索引是bools的一個好習慣。 –

這是我認爲最可能的解釋。

只有在返回非常少量的行時，您的索引纔有用（順便說一下，我不喜歡爲此原因對索引進行索引 - 您可能會考慮使用部分索引，或者甚至添加一個位置admin這是真的，因爲這將使您的索引僅適用於無論如何可能可用的情況）。

如果超過iirc，表中有10％的頁面將被檢索，計劃人員可能會選擇大量的順序磁盤I/O而不是較少量的隨機磁盤I/O，因爲你不必等待盤片轉向。尋找速度是一個很大的問題，PostgreSQL會試圖平衡這個數據與從關係中檢索的實際數據量。

您收集的統計數據表明該表或者比它小，或者有比您更多的管理員作爲用戶的一部分，因此規劃人員使用不良信息做出決定。

VACUUM ANALYZE有三件事。首先凍結所有事務可見的元組，這樣事務環繞就不成問題。然後它將可見的元組分配給空閒空間。這些都不影響您的問題。然而第三個是它分析表格並收集表格的統計數據。請記住，這是一個隨機抽樣，因此有時可以關閉。我的猜測是，之前的運行，它抓住了很多管理員的頁面，因此嚴重高估了系統管理員的數量。

這可能是仔細檢查您的autovacuum設置的好時機，因爲統計數據在其他地方也可能過時了，但這遠非確定。特別是，基於成本的真空設置有時會使得真空永遠不會完全趕上。

來源

2012-09-02 02:04:24

我的Postgres數據庫沒有使用我的索引;我解決了它，但不明白修復，任何人都可以解釋發生了什麼？

回答

相關問題