SQL優化是我們經常會遇到的問題，無論你是專職的數據分析人員還是全棧開發大神或者是CURD搬運工。

　　我們在工作中經常會聽到這樣的聲音：“查詢慢?加個索引吧”。雖然加索引並不一定能解決問題，但是這體現了SQL優化的思想。

　　而數據庫主要由三部分組成，分別是解析器、優化器和執行引擎。

　 其執行邏輯是我們輸入的SQL語句通過解析器解析成關系表達式，通過優化器把關系表達式轉換成執行計劃，最終通過執行引擎進行執行。所以優化器在很大程度上決定了一個系統的性能。優化器的作用就好比找到兩點之間的最短路徑。

　　上篇文章我們提到了Calcite，Calcite本身就支持兩種優化方式分別是RBO和CBO。

　　RBO

　　RBO(Rule-Based Optimizer) 基於規則的優化器。是根據已經制定好的一些優化規則對關系表達式進行轉換，最終生成一個最優的執行計劃。它是一種經驗式的優化方法，優化規則都是預先定義好的，只需要將SQL按照優化規則的順序往上套就行，一旦滿足某個規則則進行優化。

　　這樣的結果就是同樣一條SQL，無論讀取的表中的數據是怎樣的，最後生成的執行計劃都是一樣的(優化規則都一樣)。而且SQL的寫法不同也很有可能影響最終的執行計劃，從而影響SQL的性能(基於優化規則順序執行)。

　　所以說，雖然RBO是一個老司機，知道常見的套路，但是當路況不同時，無法針對性的達到最佳的效果。

　　CBO

　　CBO(Cost-Based Optimizer)基於代價的優化器。根據優化規則對關系表達式進行轉換，生成多個執行計劃，最後根據統計信息和代價模型計算每個執行計劃的Cost。從中挑選Cost最小的執行計劃作為最終的執行計劃。

　　從描述來看，CBO是優於RBO的，RBO只認規則，對數據不敏感，而在實際的過程中，數據的量級會嚴重影響同樣SQL的性能。所以僅僅通過RBO生成的執行計劃很有可能不是最優的。而CBO依賴於統計信息和代價模型，統計信息的準確與否、代價模型是否合理都會影響CBO選擇最優計劃。

　　目前各大數據庫和大數據計算引擎都已經在使用CBO了，比如Oracle、Hive、Spark、Flink等等。

　　動態CBO

　　顧名思義，就是在執行計劃生成的過程中動態優化的方式。隨著大數據技術的飛速發展，靜態的CBO已經無法滿足我們SQL優化的需要了，靜態的統計信息無法提供準確的參考，在執行計劃的生成過程中動態統計才會得到最優的執行計劃。

?

分享：SQL優化器簡介