為什麼需要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去列舉