PG：查詢計劃器與random_page_cost
查詢計劃器與random＿page＿cost
本周小貼士比較奇怪，基于我們今天遇到的一個問題。將簡訊的鏈接存儲到一個簡單數據庫中：
CREATE TABLE links （
uid CHAR（60） PRIMARY KEY，
data TEXT，
timestamp INT
）
CREATE INDEX idx＿trgm ON links USING GIN （data gin＿trgm＿ops）
當然，這個設計比較爛。但僅供內部使用，我只是一個粗略的想法原型。數據是一個包含json（I know， I know．．．）的文本，以同樣可怕的方式檢查鏈接的存在：
SELECT ＊ FROM links WHERE data ILIKE ＇％whatever we want％＇ LIMIT 1；
在低容量下運行很好，但查詢時間偶爾會超過300ms，很好奇這是為啥？
執行EXPLAIN ANALYZE后，發現PG根本沒使用GIN索引，而是使用了全表掃描。但是如果去掉LMIT 1，查詢將使用索引，執行只需要5ms。為什么PG會忽略索引？
PG的查詢規劃器并不是真正基于人們做一些荒唐的事情。比如使用ILIKE進行全表掃描，關心的是走索引快還是全表掃描快。變量random＿page＿cost用于決定使用索引的代價是否值得，或者和seq＿page＿cost合作使用。
這種情況下，索引掃描是值得的，但是查詢規劃器不同意。因為看起來很簡單的LIMIT 1，只找到一個結果就可以停止。并繼續進行全表掃描。
SET random＿page＿cost ＝ 1；
EXPLAIN ANALYZE SELECT ＊ ．．． LIMIT 1；
［see the index being used］
SET random＿page＿cost ＝ DEFAULT；
EXPLAIN ANALYZE SELECT ＊ ．．． LIMIT 1；
［see the index NOT being used］
除了明顯的“修復那個糟糕的模式”，看看PG會做什么，如果覺得索引掃描和順序掃描比代價低。因此如果最終得到的查詢使用索引，那么有必要嘗試一下，通過EXPLAIN ANALYZE分析。
分享
請輸入評論內容...
請輸入評論/評論長度6~500個字
最新活動更多
-
11月7日立即參評>> 【評選】維科杯·OFweek 2025（第十屆）物聯網行業年度評選
-
11月20日立即報名>> 【免費下載】RISC-V芯片發展現狀與測試挑戰-白皮書
-
即日-11.25立即下載>>> 費斯托白皮書《柔性：汽車生產未來的關鍵》
-
11月27日立即報名>> 【工程師系列】汽車電子技術在線大會
-
11月28日立即下載>> 【白皮書】精準洞察 無線掌控——283FC智能自檢萬用表
-
12月18日立即報名>> 【線下會議】OFweek 2025（第十屆）物聯網產業大會
