PostgreSQL:復(fù)合索引和多個(gè)索引哪個(gè)好?
當(dāng)前位置:點(diǎn)晴教程→知識(shí)管理交流
→『 技術(shù)文檔交流 』
復(fù)合索引和多個(gè)索引關(guān)于索引的使用,有一個(gè)最常見問題:是為每個(gè)列創(chuàng)建一個(gè)索引更好,還是為 然而,無論您如何定義索引,都存在單個(gè)索引無法完美完成的查詢;例如,帶有兩個(gè)或多個(gè)獨(dú)立范圍條件的查詢,如下例所示:
在沒有過濾謂詞的情況下,不可能定義出支持此查詢的 B 樹索引。為了解釋,你只需要記住一個(gè)索引就是一個(gè)鏈表。 如果將索引定義為 無論您如何扭轉(zhuǎn)和調(diào)整索引的定義,條目始終沿一條鏈排列。小的條目在一端,大的條目在另一端。因此,一個(gè)索引只能支持一個(gè)范圍條件作為訪問謂詞。支持兩個(gè)獨(dú)立的范圍條件需要第二個(gè)軸線,比如像一個(gè)棋盤。然后,上面的查詢將匹配來自棋盤一角的所有條目,但索引不像一個(gè)棋盤 — 它就像一條鏈。沒有角落。 當(dāng)然,您可以接受過濾謂詞,并使用多列索引。不管怎樣,在許多情況下,這是最好的解決方案。然后,索引的定義應(yīng)該首先提及選擇率更高的列,以便它可以同訪問謂詞一起使用。每次創(chuàng)建一個(gè)復(fù)合索引時(shí),都必須明智地選擇列的順序。但是,有一種誤解是,您應(yīng)該始終將選擇率最高的列放在第一個(gè)位置;那是錯(cuò)誤的。
另一種選擇是使用兩個(gè)單獨(dú)的索引,每個(gè)列一個(gè)。然后,數(shù)據(jù)庫必須首先掃描這兩個(gè)索引,然后合并結(jié)果。只是重復(fù)的索引查找,就已經(jīng)涉及更多的工作了,因?yàn)閿?shù)據(jù)庫必須遍歷兩個(gè)索引樹。此外,數(shù)據(jù)庫需要大量內(nèi)存和 CPU 時(shí)間,來組合中間結(jié)果。
組合多個(gè)索引PostgreSQL 能夠組合多個(gè)索引,來處理單個(gè)索引掃描無法實(shí)現(xiàn)的情況。“組合多個(gè)索引” 的文檔中詳細(xì)解釋了相關(guān)的算法。 在一個(gè)數(shù)據(jù)倉庫的世界中,會(huì)有許多不可預(yù)測(cè)的臨時(shí)查詢。只需單擊幾下,即可將任意條件組合到您選擇的查詢中。無法預(yù)測(cè)出 多個(gè)索引的優(yōu)點(diǎn)是,它們可以很容易地組合。這意味著在單獨(dú)地索引每個(gè)列時(shí),您可以獲得不錯(cuò)的性能。相反,如果您提前知道查詢,以便您可以創(chuàng)建定制的多列 B 樹索引,則它仍然會(huì)比組合多個(gè)索引更快。 在沒有更好的訪問路徑的情況下,PostgreSQL 會(huì)將多個(gè) B 樹索引掃描的結(jié)果轉(zhuǎn)換為內(nèi)存中的位圖結(jié)構(gòu)。這些結(jié)果可以高效地組合起來。位圖結(jié)構(gòu)不是持久化存儲(chǔ)的,而會(huì)在語句執(zhí)行后被丟棄,從而避免了寫數(shù)據(jù)時(shí)擴(kuò)展性差的問題。缺點(diǎn)是它需要大量的內(nèi)存和 CPU 時(shí)間。畢竟,這種方法也算是優(yōu)化器最后的一種選擇了。 該文章在 2025/1/16 9:57:46 編輯過 |
關(guān)鍵字查詢
相關(guān)文章
正在查詢... |