Lecture 14 & 15 Query Planning & Optimization
為什麼需要query optimization
因為SQL是宣告式的
其實直到現在,任然有兩種流派,一種是資料庫幫助優化query還有一種是自己寫運算元,比如flink
資料庫優化方式,也就是寫SQL
- 啟發式:只需要檢視元資料,不需要檢視真正的資料
- 基於代價的搜尋:類似於回溯,需要計算代價函式
query的執行架構
- 將query 語句重寫,一些小的優化
- 將query 解析成語法樹
- 將語法樹中的
表名,列名之類的
轉換成實際實體地址(Internal ID) - Logical Plan是將原來的語法樹轉變成標準的樹,這裡叫
正規化
比如說是樹轉化為二叉樹 - 將初始的未優化的Logical plan傳入optimizer
- 根據是啟發式還是代價式的優化,optimizer還需要其他資料,比如啟發式需要元資料,代價式需要代價模型
- 最後生成Physical Plan,也就是真實的運算元
LOGICAL VS. PHYSICAL PLANS
optimizer會將logical plan轉化為physical plan,比如 inner join轉化為nested loop,hash join或者merge join
Relational Algebra Equivalence
這個Relational Algebra Equivalence是做優化的基本原理
謂詞推到與投影推到
刪除不必要的謂詞
Heuristics / Rules 啟發式/規則優化
啟發式優化並沒有使用代價模型,不能夠比較plan之間的好壞,不需要實現理解資料庫的內容
LOGICAL QUERY OPTIMIZATION
SPLIT CONJUNCTIVE PREDICATES
PREDICATE PUSHDOWN
REPL ACE CARTESIAN PRODUCTS
將所有的笛卡爾積通過join predicate轉換為join語句
PROJECTION PUSHDOWN
NESTED SUB-QUERIES
解構子查詢
將子查詢與父查詢寫成一個查詢
分離子查詢,先執行子查詢得到一個臨時表
EXPRESSION REWRITING
?
Cost-based Search
Cost Estimation
代價模型只在內部有效
代價模型的組成部分:
如果使用了選擇基數,那麼就是假設資料是均勻的
這裡sel類似於概率,在table滿足predicate P的tuple的數量佔所有tuple的比例
select cardinality所做的一些假設
#
是指數量
列之間常常不是獨立的,比如這裡的只有製造商Honda
能夠製造車品牌Accord
,那麼這兩個列是相關的
一般相關性強的列,可以先將它們join,再計算selectivity
un-uinform的資料估計
histogram
對於不均勻的資料,可以用一些方法統計資料
比如EQUI-WIDTH HISTOGRAM
,EQUI-DEPTH HISTOGRAMS
對於EQUI-DEPTH HISTOGRAMS
需要去估計一個數據的頻率,比如5,那就是1/5的概率出現在第一桶中,第一個桶子的數出現的概率為1/4,那麼5的資料頻率就是1/20
sketch
通過概率來估計資料的存在可能性
sampling
抽樣
Plan Enumeration
通過selectivity of predicates,可以估計每一個運算元的傳遞資料的數量,這樣一來就可以計算query plan的代價
在基於規則的重寫plan之後,也就是heuristic優化,再之後通過代價模型列舉所有的query plan,在列舉完所有plan或者枚舉了一定的時限之後,選出最佳的plan
對於不同型別的query plan,採取不同的優化策略
Single-Relation Query Plans
一般只用啟發式就好了
sargable
指可以按照引數查詢,就是指存在index去查詢
Multi-Relation Query Plans
左深樹能夠適應管道流式plan?右邊兩種plan需要暫存join結果
一般使用dp去列舉