PostgreSQL查詢速度慢如何解決

PostgreSQL查詢速度慢如何解決？針對(duì)這個(gè)問(wèn)題，這篇文章詳細(xì)介紹了相對(duì)應(yīng)的分析和解答，希望可以幫助更多想解決這個(gè)問(wèn)題的小伙伴找到更簡(jiǎn)單易行的方法。

并非每個(gè)PostgreSQL查詢都會(huì)自動(dòng)使用索引，只有在表的大小超過(guò)一個(gè)最小值，并且查詢只會(huì)選中表中較小比例的記錄時(shí)才會(huì)采用索引。這是因?yàn)樗饕龗呙枰鸬碾S即磁盤(pán)存取可能比直接地讀取表（順序掃描）更慢。

為了判斷是否使用索引，PostgreSQL必須獲得有關(guān)表的統(tǒng)計(jì)值。這些統(tǒng)計(jì)值可以使用 VACUUM ANALYZE，或 ANALYZE 獲得。 使用統(tǒng)計(jì)值，優(yōu)化器知道表中有多少行，就能夠更好地判斷是否利用索引。 統(tǒng)計(jì)值對(duì)確定優(yōu)化的連接順序和連接方法也很有用。在表的內(nèi)容發(fā)生變化時(shí)，應(yīng)定期進(jìn)行統(tǒng)計(jì)值的更新收集。
索引通常不用于 ORDER BY 或執(zhí)行連接。對(duì)一個(gè)大表的一次順序掃描，再做一個(gè)顯式的排序通常比索引掃描要快。
但是，在 LIMIT 和 ORDER BY 結(jié)合使用時(shí)經(jīng)常會(huì)使用索引，因?yàn)檫@只會(huì)返回表的一小部分。 實(shí)際上，雖然 MAX() 和 MIN() 并不使用索引，通過(guò)對(duì) ORDER BY 和 LLIMIT 使用索引取得最大值和最小值也是可以的：
SELECT colFROM tabORDER BY col [ DESC ]LIMIT 1;
如果你確信PostgreSQL的優(yōu)化器使用順序掃描是不正確的，你可以使用SET enable_seqscan TO 'off' 然后再次運(yùn)行查詢，你就可以看出使用一個(gè)索引掃描是否確實(shí)要快一些。當(dāng)使用通配符操作，例如 LIKE 或 ~ 時(shí)，索引只能在特定的情況下使用。
比如字符串的開(kāi)始部分必須是普通字符串，也就是LIKE模式不能以 % 打頭。~（正則表達(dá)式）模式必須以 ^ 打頭。
字符串不能以匹配多個(gè)字符的模式類(lèi)打頭，例如 [a-e]。
大小寫(xiě)無(wú)關(guān)的查找，如ILIKE和 ~* 等不使用索引。
在做 initdb 時(shí)必須采用缺省的本地設(shè)置Clocale，因?yàn)橄到y(tǒng)不可能知道在非C locale情況時(shí)下一個(gè)最大字符是什么。在這種情況下，你可以創(chuàng)建一個(gè)特殊的text_pattern_ops索引來(lái)用于LIKE的索引。

關(guān)于PostgreSQL查詢速度慢如何解決問(wèn)題的解答就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，如果你還有很多疑惑沒(méi)有解開(kāi)，可以關(guān)注億速云行業(yè)資訊頻道了解更多相關(guān)知識(shí)。