作者：徒南
優化器技術被公認爲數據庫領域中最有挑戰性的技術之一，同時也是對數據庫性能影響最大的一個模塊。優化器直接影響SQL具體如何運行的執行計劃，好的執行計劃可以在毫秒內完成計算，而壞的執行計劃則可能是分鐘級或小時級別，兩者性能可以相差成千上百倍。這篇文章將會爲大家介紹PolarDB-X優化器的技術選型理由、技術架構與核心特性，幫助大家更深入地瞭解PolarDB-X優化器。
從技術歷史發展的角度看，優化器技術演進經歷了大致四個階段：
以INGRES、早期Oracle爲代表的啓發式優化技術，主要優化手段有過濾條件下推，列裁剪，之後再做基於Cardinality的Join順序調整。純啓發式優點就是簡單，缺點是當查詢稍微複雜就會導致找不到好的執行計劃，並且會依賴一些很trick的魔數來調優。
以System-R、早期IBM DB2、以及絕大多數開源數據庫(MySQL, PostgreSQL)爲代表的啓發式+基於代價的Join Reorder優化技術。優點相比於純啓發式優化，優化器針對（複雜查詢）Join順序，會基於代價利用自底向上的動態規劃選擇最優的Join順序。缺點是搜索空間比較受限不一定能找到最優的執行計劃，代價模型中需要顯式考慮像排序的物理屬性。
以IBM STARBURST、DB2、Oracle爲代表的基於轉換規則及代價的優化器技術。相比於階段2，除了考慮代價，這類優化器已經抽象出作用於關係代數算子的轉換規則（可以通過DSL編寫）。優點是從工程角度上更易理解，維護，測試覆蓋。缺點是優化規則會存在複雜的依賴關係，應用順序需要人爲指定。
以 Volcano/Cascades、SQL Server爲代表的基於規則轉換及代價的自頂向下動態規劃優化技術（Volcano/Cascades模型）。相比於階段3，它將優化的搜索過程做成了統一的框架，添加新的優化只需要關注優化規則本身，不需要關注規則的應用順序，具有很高的擴展性。同時自頂向下的搜索具有一個很吸引人的特性就是搜索空間的剪枝，剪枝可以保證執行計劃最優性的情況下減少搜索空間的搜索，提升優化效率。另外優化器作爲一個數據庫領域中很複雜的模塊，任何的改動都可能涉及大量SQL的性能變化，從軟件工程的角度，藉助Volcano/Cascades模型的模塊化及擴展性，優化器的性能可以被持續地調優和改進。
正是基於上面的考慮，PolarDB-X優化器被設計成一款以Volcano/Cascades模型作爲框架的基於代價的優化器，它可以爲每一條SQL構造出搜索空間，並根據數據的統計信息，基數估計，算子代價模型爲搜索空間中的執行機計劃估算出執行所需要的代價(CPU/MEM/IO/NET)，最終選出代價最小的執行計劃作爲SQL的具體執行方式。我們知道PolarDB-X作爲一款雲原生分佈式數據庫，具有在線事務及分析的處理能力(HTAP)、計算存儲分離、全局二級索引等重要特性，PolarDB-X優化器在這些特性中扮演了非常核心的角色。
優化器架構
優化器接受到SQL後會將它解析、轉換成由關係代數算子組成的邏輯執行計劃。整個PolarDB-X優化器中的具體優化手段都通過轉換規則(Transformation Rule)來表達，轉換規則會匹配特定結構的關係代數算子並將其轉成等價的算子。
PolarDB-X的優化器的優化階段主要分爲三個：
Query Rewriter，基於RBO的啓發式優化階段，處理傳統的邏輯優化如：子查詢去關聯化，列裁剪，謂詞推導與下推，啓發式Join Reorder（超多張表）等。這個優化階段的特性是不斷啓發式地對同一個執行計劃做邏輯優化，優化通常很快，且只做收益非常明確的優化器。
Plan Enumerator，基於CBO的Volcano/Cascades模型，是最爲核心優化階段，它會應用轉換規則爲計劃生成搜索空間，既包含了邏輯優化如：Join Reorder（Bushy,Zig-Zag,Left Deep空間動態選擇），算子交換，計算下推等，也包含物理優化如：全局二級索引選擇，物理算法選擇等。搜索空間被完全展開並搜索過後，每個物理執行計劃都會根據具體的物理算子估算出執行所需要的代價（通過CPU/MEM/IO/NET表示）。最後代價最低的物理執行計劃將會被選擇出來。在整個優化過程中，這一步耗時佔比最高，因爲它需要考慮整個搜索空間。
MPP Planner，多機並行計算優化階段，處理並行算子生成，算子間Shuffle的選擇與消除，RunTimeFilter的生成及下推等。這一優化階段專門用於優化OLAP的查詢，保證可以充分利用多個節點的計算資源。
此外還有統計信息、代價模型、基數估計(Cardinality Estimation)等重要模塊，好的優化效果依賴於準確的數據統計信息，PolarDB-X維護了豐富的統計信息用於輔助優化器，我們會爲每張表維護行數，直方圖，列長度，NDV值等統計信息。PolarDB-X的代價模型充分考慮了計算存儲分離架構下的算子執行代價，與傳統數據庫相比會更精細地考慮網絡的代價。
核心特性
HTAP
在HTAP混合負載處理方面，PolarDB-X提供智能路由的能力。我們知道傳統的OLTP和OLAP的解決方案是基於簡單的讀寫分離或者ETL模型，它們存在存儲成本高、實時性差、鏈路和維護成本高等劣勢。通過PolarDB-X可以統一處理HTAP負載，保證TP事務低延遲，同時保證AP分析查詢充分利用計算資源，且保證數據的強一致。優化器在HTAP的負載識別中起了關鍵的作用。優化器會基於代價分析出查詢的CPU，內存，IO，網絡等核心資源消耗量，將請求區分爲OLTP與OLAP請求。OLTP請求被路由至主副本執行, 相比於傳統的讀寫分離方案能夠提供更低的延遲。而分析出的OLAP請求將會通過MPP並行優化階段，生成多機分佈式的執行計劃，下發至只讀計算集羣計算，訪問只讀副本，提供物理隔離，同時可以利用只讀副本一致性讀能力，保證強一致讀。通過智能路由，用戶可以非常透明地使用PolarDB-X同時處理OLTP及OLAP的訴求。
計算下推
PolarDB-X支持Partition Aware的計算下推。我們知道在計算與存儲分離的架構下，我們獲得了幾乎無限彈性擴展計算節點的scale out能力，但代價是計算與存儲間的網絡交互開銷。爲了儘可能避免這一開銷，可以通過計算下推，減少網絡交互，計算離數據更近，計算效率獲得提升，因此計算下推成了非常重要的優化手段。PolarDB-X用戶大量使用拆分表（及廣播表），將數據根據拆分方式打散至不同的分片上。PolarDB-X可以基於代價充分考慮存儲（如存儲的計算模型）及數據（是否具有索引）等特性，將查詢中的部分計算(如：Join，Agg，Sort)下推至存儲層進行計算。以TP場景下的Join的下推爲例：如果Join不下推，我們會面臨一個網絡Lookup，通過網絡Lookup的性能會劣於本地的磁盤Lookup，而通過計算下推我們就可以獲得彈性擴容的同時，享受單機數據庫的性能體驗。
全局二級索引選擇
PolarDB-X爲用戶提供全局二級索引，並提供數據強一致性。在建立全局二級索引後，優化器可以立馬感知到表存在全局二級索引，併爲查詢優化出更優的查詢計劃。以訂單爲例子，用戶將訂單表按照買家維度作拆分，以買家維度作爲查詢可以獲得非常好的性能。但按賣家維度進行查詢時，需要將所有數據分片查詢一遍才能得到完整結果。而通過爲訂單表建立賣家維度的全局二級索引，優化器就可以優化出訪問全局二級索引（回表）的執行計劃，避免全分片掃描，提升性能。另外，全局二級索引支持覆蓋索引，優化器結合列裁剪優化，當發現用戶查詢表的列被全局二級索引覆蓋時，可以做到只訪問全局二級索引，避免回表。全局二級索引還可以和Partition Aware的計算下推做共同優化，例如：兩張表的Join的場景，兩表的拆分方式不一致導致Join無法下推的時候，我們可以將表按照Join Key共同的維度建立全局二級索引，達到計算下推的目的。
優化例子
下面讓我們一起通過一個TPCH Q3作爲例子看看PolarDB-X如何優化一條SQL吧。首先TPCH Q3這條SQL會被轉化爲如下的邏輯執行計劃(LogicalPlan)
這個邏輯執行計劃包含Agg、Join、Filter、Project、LogicalView等關係代數算子，PolarDB-X通過LogicalView算子來抽象下發至存儲執行的Plan(所以下推算子在優化中就是將算子下推進LogicalVIew算子)。
接着我們一步一步看一下RBO，CBO，MPP三個優化階段分別做了哪些優化。
RBO啓發式階段，可以看到經過RBO後的邏輯執行計劃已經將Filter，Project等算子下推到了LogicalVIew，也就是完成了列裁剪，謂詞下推等優化。同時我們可以看到原來Orders，Lineitem表也因爲擁有相同拆分規則被下推到了同一個LogicalVIew，完成了計算的下推優化。
CBO基於代價的優化階段，可以看到邏輯執行計劃變成了物理執行計劃，其中Join和Agg分表選擇使用HashJoin和HashAgg作爲物理算子。在這背後，優化器實際上已經考慮了不同的Join順序，不同的Join與Agg算法，被選擇出來的就是具有最低代價的物理執行計劃。
MPP分佈式優化階段，可以看到在算子間多了Exchange算子，用於描述數據如何在多個計算節點間進行Shuffle。這使得執行器可以知道如何在多個計算節點中傳輸數據，並行計算。此外，還可以看到RunTimeFilter生成，並下推到存儲節點執行提前過濾數據，減少網絡傳輸開銷。
總結
PolarDB-X 查詢優化器主要基於 Volcano/Cascades 模型設計，是一個基於代價的優化器（CBO），優化過程主要分爲查詢改寫、計劃枚舉、MPP 優化三個階段。其中，查詢改寫階段負責啓發式優化規則（例如查詢下推）；計劃枚舉階段負責索引選擇和決定 Join Order 等，是最核心的階段；如果優化器判斷執行計劃代價較高、需要 MPP 執行，則會通過 MPP 優化階段將執行計劃進一步優化爲分佈式執行計劃。通過這樣的設計，讓 PolarDB-X 能很好的適應 HTAP 場景，兼顧 TP 與 AP 兩種不同模式的流量。