Postgre查詢優化 --演算法篇
阿新 • • 發佈：2019-01-08
前言
這部分的內容也是基於上章節提到的資料庫優化的各種操作，比如邏輯層面，以及物理層面的，而這節將從物理層面來介紹PG 基於演算法的優化，提到PG的演算法優化就從PG引以為豪的遺傳演算法來介紹以及對比動態規劃的優缺點來分別得出結論，什麼情況下使用PG得到最好的解決方案。
動態規劃演算法
簡單的介紹動態規劃演算法，表示在多表進行關聯操作的時候，會從第1層關係到N-1層關係，每一層都算出最優的路徑，然後跟第N層關係進行關聯得到最後的結果，在這個過程中會分為兩個階段，第一個階段為初始化階段，構造第一層關係，第二階段是歸納，生成1到N-1層關係，然後跟第N層進行關聯。這時候就產生左深樹，如果是從第K層開始構造第一層關係往外兩頭進行關聯，這時候就產生緊密樹。
對比緊密樹的處理過程
遺傳演算法
上面提到的動態規劃確實可以得到每一層的最優的路徑然後跟最後一層關聯得到最後的結果，但是這個演算法會產生空間膨脹的問題，嚴重的影響到查詢效能，這就需要到遺傳演算法來解決這個空間膨脹的問題，官方推薦的是12張表或者以上的關聯，推薦使用遺傳演算法來解決查詢過程空間膨脹的問題，遺傳演算法之所以能解決空間膨脹的問題在於提供的gimme型別的函式，進行順序雜交，位置雜交等。
書中詳細的介紹了演算法的重點函式以及資料結構，在這裡就不詳細的秒殺，有興趣的讀者可以下載PG的原始碼對著書中的介紹來學習，這裡主要還是說遺傳演算法的優勢，染色體適應性強，有效解決空間膨脹的問題，與動態規劃對比只要有以下的情況
現在回想起來電商的專案確實裡面業務有複雜的情況需要使用到超過10個表的關聯操作，使用PG來替代Mysql確實是出於PG強大的遺傳演算法的理解。