1. 程式人生 > 其它 >Lecture 14 & 15 Query Planning & Optimization

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去列舉