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即可。
基於取樣的路徑規劃
1 prm，這是乙個圖結構。首先在空間內隨機撒一些點，然後清除障礙物內的點，然後把其他的點相互較近的連起來。優點 概率完備的，只要有乙個圖並且這個圖上有乙個最優解，那麼這個解就是可以找出來的 缺點 需要解決兩個點之間value值的問題，並且一開始就沒有專注找到乙個最優解。解決方法 三個階段 lear...
基於搜尋的路徑規劃演算法
於圖搜尋的方法主要包括dijstra方法，a演算法，jps演算法，a演算法是dijstra演算法的拓展，jps演算法是a 演算法的拓展。下面為a 演算法的流程圖 從起點a開始,把它作為待處理的方格存入乙個 開啟列表 開啟列表就是乙個等待檢查方格的列表。尋找起點a周圍可以到達的方格,將它們放入 開啟列...
3 動態規劃問題中的最優路徑儲存與輸出
在動態規劃問題中，我們經常會遇到以下問題，最優解倒是求出來了，但是最優解的路徑呢？如何輸出？這確實是乙個問題，而且往往比較難喲。我這裡說的路徑是指，像在鋼條切割問題中，從哪些地方切可以達到最優化，在矩陣鏈乘問題中，從哪些地方進行組合可以使效率最高？for j 1 j i j while n 0 在以...