Oracle ORDERED提示成本vs速度

Question

因此，幾周前，我詢問了有關FIRST_ROWS（n）提示的Oracle execution plan cost vs speed。我遇到了類似的問題，但這次是在ORDERED提示下。當我使用提示時，我的執行時間顯着提高（高達90％），但查詢的EXPLAIN PLAN報告顯示成本大幅增加。在這個特定的查詢中，費用從1500到24000.

查詢的參數是paramterized，並且連接19個表來獲取數據。我會在這裏發佈它，但是它的長度是585行，並且是爲供應商的混亂，空洞的架構而寫的。除非你碰巧熟悉這個產品的用途，否則看不到它有什麼幫助。但是，在開始調整查詢之前不久，我收集了100％的架構統計信息，因此CBO在這裏並不在黑暗中工作。

我會盡量總結查詢的功能。該查詢實質上返回系統中的對象及其子級，並且構造爲一個直接連接到多個表的大型子查詢塊。第一部分返回對象ID，並且在連接到其他表之前在其查詢塊內分頁。然後，它會連接到包含子ID的幾個表。

我知道CBO並不是全部都知道或者不可信，但是真的讓我很困擾，因爲看到一個執行計劃成本高昂，它違背了我教過的很多東西。使用FIRST_ROWS提示，解決方案是提供一個值n，以便優化器可以可靠地生成執行計劃。 ORDERED提示對我的查詢是否有類似的事情發生？

Answer 1

報告的成本用於執行完整查詢，而不僅僅是第一組行。 （PostgreSQL的成本計算略有不同，因爲它提供了最初返回行和整個集合的成本）。

對於某些計劃，大部分成本是在返回第一行之前發生的（例如，在使用分類合併的情況下），對於其他計劃，初始成本非常低，但之後每行的成本相對較高例如嵌套循環連接）。

因此，如果您針對前幾行的返回和連接19個表格進行了優化，那麼使用嵌套的基於循環的計劃返回前20個可能會獲得非常低的成本。然而，對於整組行來說，該計劃的成本可能會比其他優化後的計劃的成本高得多，以返回所有行爲代價，而以返回第一行的延遲爲代價。

Answer 2

您不應該依賴執行成本來優化查詢。重要的是執行時間（以及在某些情況下的資源使用情況）。

從concept guide：

的成本是一個估計值成正比，與一個特定的計劃執行語句所需要的預期資源使用。

估計結束時，通常是因爲優化程序可用的統計信息具有誤導性。您可以通過爲優化器提供更準確的統計數據來糾正這一點。檢查統計數據是否是最新的。如果是，則可以收集其他統計信息，例如啓用在數據傾斜列上手動創建直方圖的動態統計信息收集。

另一個可以解釋相對成本與執行時間差異的因素是優化器建立在簡單的假設之上。例如：

• 沒有一個直方圖，在一列的每一個值是均勻分佈的
• 一個等式操作者將選擇的行的5％（無直方圖或動態數據）
• 在每列中的數據是獨立於在每個其他列中的數據
• 此外，對於與綁定變量的查詢，單個成本被計算爲進一步執行（即使綁定值的變化，有可能修改該查詢的基數）
• ...

這些假設是爲了使優化器可以返回一個單個數字（而不是間隔）的執行成本。對於大多數查詢來說，這些近似值並不重要，結果足夠好。

但是，您可能會發現有時情況對於優化器來說太複雜了，甚至收集額外的統計數據也無濟於事。在這種情況下，您必須手動優化查詢，方法是自己添加提示，通過重寫查詢或使用Oracle工具（如SQL profiles）。

如果Oracle可以設計一種方法來準確確定執行成本，我們絕不需要首先手動優化查詢！