通過使用變量作為參數，選擇查詢花費了太多時間

Question

當我在條件下通過硬編碼在查詢下面運行時，它運行很快：

... AND ooha.order_number BETWEEN NVL(5339914,ooha.order_number) 
    AND NVL(5339914,ooha.order_number)

但是，當我將其作為參數使用時，它花費了將近2個小時以上的太多時間

... AND ooha.order_number BETWEEN NVL(:p,ooha.order_number) 
    AND NVL(:q,ooha.order_number)

以下是我的原始代碼，請按照開發人員的觀點嘗試所有可能的解決方案：

SELECT ooha.order_number,
    hps.addressee cus_name,
    oola.line_number,
    (SELECT rtrim(extract(xmlagg(xmlelement("a",set_name                        -- query to check ship_set
      ||'/')),'//text()'),',')
    FROM oe_sets
    WHERE header_id = ooha.header_id
    AND set_type    = 'SHIP_SET'
    ) ship_set,
  msib.segment1 item_name,
  ooha.booked_date,
  oola.schedule_ship_date,
  mp.ORGANIZATION_CODE,
  oola.ordered_quantity,
  oola.subinventory,
  oola.project_id,
  (SELECT description FROM fnd_user WHERE user_id = ooha.attribute12            -- query to check Customer Delivery Partner  
  ) cdp,
  (SELECT NVL(SUM(reservation_quantity),0)                                      -- query to check Reservation Quantity
  FROM mtl_reservations
  WHERE demand_source_line_id = oola.line_id
  ) reserved_qty,
  oola.header_id,
  oola.line_id,
  msib.inventory_item_id,
  msib.organization_id,
  msib.item_type,
  msib.inventory_item_status_code,
  cic.item_cost,
  msib.ATTRIBUTE13

FROM oe_order_headers_all ooha,
  oe_order_lines_all oola,
  mtl_system_items_b msib,
  hz_cust_site_uses_all csu ,
  hz_cust_acct_sites_all cas ,
  hz_party_sites hps,
  mtl_parameters mp,
  cst_item_costs cic
WHERE ooha.header_id       = oola.header_id
AND oola.inventory_item_id = msib.inventory_item_id
AND oola.ship_to_org_id    = csu.site_use_id
AND csu.cust_acct_site_id  = cas.cust_acct_site_id
AND cas.party_site_id      = hps.party_site_id
AND oola.ship_from_org_id  = msib.ORGANIZATION_ID
AND msib.ORGANIZATION_ID   = mp.ORGANIZATION_ID
AND cic.inventory_item_id = msib.inventory_item_id
AND cic.ORGANIZATION_ID = msib.ORGANIZATION_ID
and cic.COST_TYPE_ID=1
AND oola.SUBINVENTORY LIKE 'Direct'
AND oola.item_type_code IN ('CONFIG','STANDARD')
AND oola.project_id       IS NOT NULL
AND OOLA.BOOKED_FLAG       = 'Y'
AND OOLA.OPEN_FLAG = 'Y' AND oola.ship_from_org_id IN
(SELECT ood.organization_id
FROM org_organization_definitions ood
WHERE ood.operating_unit =
  (SELECT operating_unit                                                        -- query to fetch operating unit
  FROM org_organization_definitions ood1
  WHERE ood1.organization_id = 2064
  )
) 
AND ooha.order_number BETWEEN NVL(5339914,ooha.order_number) AND NVL(5339914,ooha.order_number)
AND TRUNC(oola.schedule_ship_date) >= TRUNC(NVL(TO_DATE(null,'DD-MON-YYYY'),oola.schedule_ship_date))
AND TRUNC(oola.schedule_ship_date) <= TRUNC(NVL(TO_DATE(null,'DD-MON-YYYY'),oola.schedule_ship_date))

-游標選擇查詢結束

Answer 1

... AND ooha.order_number在NVL（：p，ooha.order_number）和NVL（：q，ooha.order_number）之間

好吧，這是Oracle優化的首要任務。 如果綁定變量都不為null並且覆蓋合理范圍，則使用嵌套循環的索引范圍掃描可能是一個不錯的計划。 但是下一次調用可能會為：p和：q指定兩個空值，在這種情況下，索引范圍掃描/嵌套循環計划將是災難性的。

Oracle的最新版本（從11g，iirc開始）具有綁定感知和綁定敏感游標的概念。 如果您想閱讀該功能，則稱為自適應游標共享。
有了該功能，如果您足夠運行此查詢，Oracle應該抓住一個事實，即不同的綁定值需要不同的計划，這樣最終您的性能會更好。 使用/*+ BIND_AWARE */提示可能有助於完成此過程。

老實說，我從來沒有像我所希望的那樣擁有這項功能。

如果需要，可以通過執行一些優化工作來使它更輕松一些。 即， ooha的訪問分為四個部分：（a）都綁定不為null，（b）p為null，q不為null，（c）p不為null，q為空，並且（d）都綁定為null。

例如：

select count(*)
from   ( SELECT * 
         FROM   oe_order_headers_all ooha
         WHERE  ooha.order_number between :p and :q
         and    :p is not null
         and    :q is not null
         UNION ALL
         select *
         from   oe_order_headers_all ooha
         WHERE  ooha.order_number >= :p
         and    :p is not null
         and    :q is null
         UNION ALL
         select *
         from   oe_order_headers_all ooha
         WHERE  ooha.order_number <= :q
         and    :p is null
         and    :q is not null
         UNION ALL
         select *
         from   oe_order_headers_all ooha
         WHERE  :p is null
         and    :q is null ) ooha;

不必這樣做-不幸的是需要這樣做。 但是，令人遺憾的是，有時它確實有幫助，我發現它比希望/等待自適應游標共享來拯救我更快，更可靠。