CBO代價解析

在過去資料庫主要使用基於規則的最佳化器（ RBO）,基於規則將SQL解析生成的關係表示式進行等價交換，形成更優的方案，例如，有一個多表查詢SQL

select a.c_id,sum(c.price) from a,b,c where a.c_id=c.c_id and c.o_id=b.o_id group by a.c_id order by sum(c.price) desc;

如果直接解析，將會把 a,b,c查詢的一部分建立為CROSS JOINS,再建立FILTER。再未最佳化的情況下，CROSS JOINS將產生大量的中間資料。即使試圖執行這樣的計劃也沒有意義。

取而代之，利用 RBO規則引擎，將會把cross join修改成按key進行兩表連線的方式。確實會比CROSS JOINS更好。

同樣的表連線，將大表放入記憶體和將小表放入記憶體明顯會有效率上的差異，但給予規則，此類設計會很複雜。

而基於 CBO，將會明顯提升效率。所以在資料庫的CBO設計中，主要參考了傳統關係型資料庫，將CPU時間、記憶體需求和網路頻寬使用率作為三個影響查詢執行效率的三個維度。

在資料庫中記為成本。同時根據表的內部統計資訊，在邏輯計劃轉換成物理計劃時，派生多個不同的物理計劃，並對每個物理計劃進行評價，估計實現這個轉換的代價。除列舉外同時考慮使用動態規劃演算法。

考慮有多個查詢同時進行，每個查詢的成本不同，如何做到更高併發的查詢計劃，需要進行權衡，這基本意味著需要以儘可能少的資源儘可能快地執行查詢。在資料庫中，使用成本概念進行建模，捕獲例如 CPU成本、記憶體需求和網路頻寬使用率之類的屬性，探索查詢執行計劃的不同變體，分配成本並進行比較，選擇總成本最低的變體執行。這種方法巧妙地平衡了叢集對於查詢響應速度、高併發等需求。

在查詢計劃中，每項操作的成本均以適合於該操作型別的計算方式及該操作涉及的資料統計資訊進行計算。
path

查詢執行計劃的拆分彙總

表掃描（讀取表；執行時與過濾器結合使用）、過濾器（ SQL的where子句或查詢計劃程式推斷出的任何其他條件）、投影（計算輸出表示式）、JOIN、聚合、排序（ORDER BY）、限制（LIMIT等）、排序和限制組合（例如order by limit）、其他。

表掃描統計

表從讀取資料的任何過濾條件的使用，例如表中如果存在分割槽，過濾條件排除掉某些分割槽後，則統計資訊將考慮使用更小的資料集，並且更加準確。

過濾統計

在進行過濾操作時將分析過濾條件，並計算估算值，包括以下：資料行透過過濾條件的機率（得到過濾器之後的預期行數）；過濾條件涉及的列的不同值的數量；不屬於過濾條件的列的不同值的數量（如果原始不同值數量大於透過過濾器的資料行的預期數量），理想狀態下，估算值 =輸入行數*非空值分數/去重值。

投影統計

按關係型理論考慮投影，投影的結果大小是可精確計算的，通常，投影與過濾器類似，不同之處在於，投影不會影響操作後的預期行數，對於投影，將計算以下型別的列統計資訊：投影產生不同值的數量， NULL投影產生的值，投影產生的最小值/最大值。如果投影表示式是直接返回的，則無需統計。如果是將其作為過濾器或連線操作時，則這些統計資訊對於正確估計過濾器條件或連線返回的行數很重要。

CBO從概念上來說是簡單的，流程上考慮替代查詢計劃，選擇並執行最佳計劃，但細節上比傳統關係型資料庫需要考慮的更多，傳統資料庫基本只需要考慮磁碟IO即可。

在未使用 CBO最佳化器前，針對1TB資料量的TPC-DS資料，在查詢某些SQL時（如query72）,需要至少三個小時或以上才可以出結果，而在增加CBO最佳化器後，進行查詢將時間縮短到了5分鐘左右，效率整整提升了至少10倍到100倍。

以上為基於代價解析的最優路徑規劃， 「分散式技術專題」是國產資料庫 hubble 團隊精心整編，專題會持續更新，歡迎大家保持關注。