什麼是rbo？
什麼是cbo？
我們在工作中經常會聽到這樣的聲音：「sql查詢慢？你給資料庫加個索引啊」。雖然加索引並不一定能解決問題，但是這初步的體現了sql優化的思想。
而資料庫主要由三部分組成，分別是解析器、優化器和執行引擎。
其執行邏輯是我們輸入的sql語句通過解析器解析成關係表示式，通過優化器把關係表示式轉換成執行計畫，最終通過執行引擎進行執行。所以優化器在很大程度上決定了乙個系統的效能。優化器的作用就好比找到兩點之間的最短路徑。
上篇文章我們提到了calcite，calcite本身就支援兩種優化方式分別是rbo和cbo。
rbo(rule-based optimizer) 基於規則的優化器。是根據已經制定好的一些優化規則對關係表示式進行轉換，最終生成乙個最優的執行計畫。它是一種經驗式的優化方法，優化規則都是預先定義好的，只需要將sql按照優化規則的順序往上套就行，一旦滿足某個規則則進行優化。
這樣的結果就是同樣一條sql，無論讀取的表中的資料是怎樣的，最後生成的執行計畫都是一樣的（優化規則都一樣）。而且sql的寫法不同也很有可能影響最終的執行計畫，從而影響sql的效能（基於優化規則順序執行）。
所以說，雖然rbo是乙個老司機，知道常見的套路，但是當路況不同時，也無法針對性的達到最佳的效果。
cbo（cost-based optimizer）基於代價的優化器。根據優化規則對關係表示式進行轉換，生成多個執行計畫，最後根據統計資訊和代價模型計算每個執行計畫的cost。從中挑選cost最小的執行計畫作為最終的執行計畫。
從描述來看，cbo是優於rbo的，rbo只認規則，對資料不敏感，而在實際的過程中，資料的量級會嚴重影響同樣sql的效能。所以僅僅通過rbo生成的執行計畫很有可能不是最優的。而cbo依賴於統計資訊和代價模型，統計資訊的準確與否、代價模型是否合理都會影響cbo選擇最優計畫。
目前各大資料庫和大資料計算引擎都已經在使用cbo了，比如oracle、hive、spark、flink等等。
動態cbo，就是在執行計畫生成的過程中動態優化的方式。隨著大資料技術的飛速發展，靜態的cbo已經無法滿足我們sql優化的需要了，靜態的統計資訊無法提供準確的參考，在執行計畫的生成過程中動態統計才會得到最優的執行計畫。
那麼優化器的執行過程是怎樣的呢？又有哪些優化規則呢？（請看下回分解~）
MongoDB 執行計畫 優化器簡介 上
最近，由於工作需求去了解一下query是如何在mongodb內部進行處理，從而丟給儲存引擎的。裡面涉及了query執行計畫和優化器的相關 mongodb整體思路設計的乾淨利落，有些地方深入挖一下其實還是能有些優化點的。本文會涉及一條query被parse之後一路走到引擎之前，都做了那些事情，分析基於...
mysql 優化隱藏器 優化Sql語句，避免查詢慢
前言 在面試過程中，經常會被問到，如果sql語句執行耗時過長，該如何優化sql，提高查詢效率，在此我根據自己的實際經驗，做如下總結。一 explain分析sql語句 sql優化經常用到explain來檢視sql語句的執行計畫，以下5點是我們重點關注的地方 explain執行sql語句以後顯示的執行計...
Sql注入 簡介
所謂sql注入，就是通過把sql命令插入到web表單遞交或輸入網域名稱或頁面請求的查詢字串，最終達到欺騙伺服器執行惡意的sql命令。我們永遠不要信任使用者的輸入，我們必須認定使用者輸入的資料都是不安全的，我們都需要對使用者輸入的資料進行過濾處理。sql注入主要是通過對單引號進行轉義來完成 設定 na...