我有一個簡單的表格，用于存盤不同 id 的單詞。
CREATE TABLE words (
id INTEGER,
word TEXT,
);
CREATE INDEX ON words USING hash (id);
CREATE INDEX ON words USING hash (word);
現在我只想計算給定單詞出現的次數。我的實際查詢有點不同，涉及其他過濾器。
SELECT COUNT(1) FROM "words"
WHERE word = 'car'
我的表有十億行，但這個特定查詢的答案大約是 45k。我希望單詞上的索引會使查詢超快，但執行起來仍然需要 1 分 20 秒，這看起來很不合理。作為比較，SELECT COUNT(1) FROM "words"需要 1 分鐘 57。
這是解釋的輸出：
Aggregate (cost=48667.00..48667.01 rows=1 width=8)
-> Bitmap Heap Scan on words (cost=398.12..48634.05 rows=13177 width=0)
Recheck Cond: (word = 'car'::text)
-> Bitmap Index Scan on words_word_idx (cost=0.00..394.83 rows=13177 width=0)
Index Cond: (word = 'car'::text)
我不明白為什么需要重新檢查條件以及為什么這個查詢效率不高。
uj5u.com熱心網友回復：
哈希索引不將索引值存盤在索引中，僅存盤其 32 位哈希和 ctid（指向表行的指標）。這意味著他們無法自行解決哈希沖突，因此必須去表中獲取值，然后重新檢查。與 btree 索引相比，這可能涉及大量或額外的 IO，btree 索引確實存盤值并且可以支持僅索引掃描。
uj5u.com熱心網友回復：
每當索引列涉及使用以下運算子之一的比較時，您都可以使用 B-Tree 索引：
< <= = >= >
我假設您正在使用=計算有多少單詞。因此，B-Tree 索引滿足您的要求。
參考：https ://www.postgresql.org/docs/current/indexes-types.html#INDEXES-TYPES-BTREE
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/468315.html
標籤：sql PostgreSQL 索引 查询优化