假設(shè)您要查詢許多數(shù)據(jù)庫中常見的“索引提示”功能，PostgreSQL沒有提供這種功能。這是PostgreSQL團隊做出的明智決定。在這里可以找到關(guān)于為什么以及可以做什么的很好的概述。究其原因，基本上是因為它是一個性能黑客，隨著數(shù)據(jù)的變化，它會在以后引起更多的問題，而PostgreSQL的優(yōu)化器可以根據(jù)統(tǒng)計信息對計劃進行重新評估。換句話說，今天可能是一個好的查詢計劃，可能永遠不會成為一個好的查詢計劃，并且索引提示會一直強迫一個特定的查詢計劃。

您可以使用enable_seqscan和enable_indexscan參數(shù)，這是一個非常鈍的錘子，對于測試非常有用?？吹剑?/p>

檢查索引用法

enable_ 參數(shù)

這些不適合正在進行的生產(chǎn)使用。如果您在選擇查詢計劃時遇到問題，則應(yīng)查看有關(guān)跟蹤查詢性能問題的文檔。不要只是設(shè)置enable_參數(shù)并走開。

除非您有充分的理由使用索引，否則Postgres可能會做出正確的選擇。為什么？

對于小型表，順序掃描更快。

當(dāng)數(shù)據(jù)類型不正確匹配時，Postgres不使用索引，您可能需要包括適當(dāng)?shù)霓D(zhuǎn)換。

您的計劃程序設(shè)置可能會引起問題。

可能是使用的唯一有效理由

set enable_seqscan=false

是在編寫查詢并希望快速查看表中有大量數(shù)據(jù)時查詢計劃的實際情況?；蛘撸?dāng)然，如果您只是因為數(shù)據(jù)集太小而需要快速確認(rèn)查詢未使用索引的話。

有時PostgreSQL無法針對特定條件對索引進行最佳選擇。例如，假設(shè)有一個包含幾百萬行的事務(wù)處理表，其中每天有數(shù)百行，并且該表具有四個索引：transaction_id，client_id，date和description。您要運行以下查詢：

SELECT client_id, SUM(amount)

FROM transactions

WHERE date >= 'yesterday'::timestamp AND date < 'today'::timestamp AND

      description = 'Refund'

GROUP BY client_id

PostgreSQL可能選擇使用索引transactions_description_idx而不是transactions_date_idx，這可能導(dǎo)致查詢花費幾分鐘而不是不到一秒鐘的時間。在這種情況下，您可以通過以下條件強制使用日期索引：

SELECT client_id, SUM(amount)

FROM transactions

WHERE date >= 'yesterday'::timestamp AND date < 'today'::timestamp AND

      description||'' = 'Refund'

GROUP BY client_id