oracle優化-leading提示和ordered提示以及materialize提示

来源:http://www.cnblogs.com/lzfhope/archive/2017/07/07/7133678.html
-Advertisement-
Play Games

以下內容適用於oracle 10.2.0.5及其以上版本 一個查詢很慢，原始SQL如下： 表都不大，執行計劃如下： 這個執行計劃，看起來無比正常，應該要left join的都有。 但問題的關鍵在於10 步驟-- MERGE JOIN CARTESIAN。笛卡爾乘積的排序合併連接，這個需要耗費很長時間 ...


以下內容適用於oracle 10.2.0.5及其以上版本

一個查詢很慢，原始SQL如下：

 1 select 
 2  a.*
 3   from (select        
 4          ssi.ID,
 5          'small_station_info' TB,
 6          (select sbi.name
 7             from scene_base_info sbi
 8            where sbi.id = ssi.antenna_selection) as antenna_selection,
 9          ssi.antenna_height,
10          ssi.down_angle,
11          ssi.azimuth_angle,
12          ssi.ITI_ID,
13          sa.longitude,
14          sa.latitude,
15          sa.attach_id
16           from consolidation_demand cd
17           left join demand_test_info dti
18             on cd.id = dti.cd_id
19           left join demand_plan_info dpi
20             on dti.id = dpi.tdl_id
21           left join building_plan_info bpi
22             on dpi.id = bpi.dpi_id
23           left join NEAR_FAR_PLACE_INFO nfpi
24             on bpi.id = nfpi.bpi_id
25           left join SMALL_STATION_INFO ssi
26             on nfpi.id = ssi.nfpi_id
27           left join site_attachment sa
28             on TO_NUMBER(sa.longitude) is not null
29            AND TO_NUMBER(sa.latitude) > 26.074423
30            AND TO_NUMBER(sa.latitude) < 26.077573
31            AND TO_NUMBER(sa.longitude) > 119.191148
32            AND TO_NUMBER(sa.longitude) < 119.197649
33            AND sa.attach_name =
34                substr(ssi.AZIMUTH_ANGLE_PHOTO,
35                       instr(ssi.AZIMUTH_ANGLE_PHOTO, '/', -1) + 1,
36                       length(ssi.AZIMUTH_ANGLE_PHOTO))) a
37  where a.longitude is not null

表都不大，執行計劃如下：

已選擇 12 行。


執行計劃
----------------------------------------------------------
Plan hash value: 1917963167

---------------------------------------------------------------------------------------------------------------
| Id  | Operation                           | Name                    | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                    |                         |     1 |   253 |   519   (2)| 00:00:07 |
|   1 |  TABLE ACCESS BY INDEX ROWID        | SCENE_BASE_INFO         |     1 |    14 |     1   (0)| 00:00:01 |
|*  2 |   INDEX UNIQUE SCAN                 | SCENE_BASE_INFO_PK      |     1 |       |     0   (0)| 00:00:01 |
|   3 |  VIEW                               |                         |     1 |   253 |   519   (2)| 00:00:07 |
|*  4 |   FILTER                            |                         |       |       |            |       |
|*  5 |    HASH JOIN OUTER                  |                         |     1 |   251 |   519   (2)| 00:00:07 |
|*  6 |     HASH JOIN OUTER                 |                         |    83 |  8134 |   505   (1)| 00:00:07 |
|*  7 |      HASH JOIN OUTER                |                         |    83 |  7304 |   501   (1)| 00:00:07 |
|*  8 |       HASH JOIN OUTER               |                         |    83 |  6391 |   493   (1)| 00:00:06 |
|*  9 |        HASH JOIN OUTER              |                         |    83 |  5478 |   271   (1)| 00:00:04 |
|  10 |         MERGE JOIN CARTESIAN        |                         |    36 |  2052 |    21   (0)| 00:00:01 |
|* 11 |          TABLE ACCESS BY INDEX ROWID| SITE_ATTACHMENT         |     1 |    53 |    16   (0)| 00:00:01 |
|* 12 |           INDEX RANGE SCAN          | IDX_SITE_ATTACHMENT_JWD |     1 |       |    15   (0)| 00:00:01 |
|  13 |          BUFFER SORT                |                         |  6725 | 26900 |     5   (0)| 00:00:01 |
|  14 |           INDEX FAST FULL SCAN      | PK_CONSOLIDATION_DEMAND |  6725 | 26900 |     5   (0)| 00:00:01 |
|  15 |         TABLE ACCESS FULL           | DEMAND_TEST_INFO        | 15459 |   135K|   249   (1)| 00:00:03 |
|  16 |        TABLE ACCESS FULL            | DEMAND_PLAN_INFO        |  8787 | 96657 |   221   (1)| 00:00:03 |
|  17 |       TABLE ACCESS FULL             | BUILDING_PLAN_INFO      |  3244 | 35684 |     8   (0)| 00:00:01 |
|  18 |      TABLE ACCESS FULL              | NEAR_FAR_PLACE_INFO     |   389 |  3890 |     3   (0)| 00:00:01 |
|  19 |     TABLE ACCESS FULL               | SMALL_STATION_INFO      |   594 | 90882 |    13   (0)| 00:00:01 |
---------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("SBI"."ID"=:B1)
   4 - filter("SA"."ATTACH_NAME"=SUBSTR("SSI"."AZIMUTH_ANGLE_PHOTO",INSTR("SSI"."AZIMUTH_ANGLE_PHOTO",'
              /',-1)+1,LENGTH("SSI"."AZIMUTH_ANGLE_PHOTO")))
   5 - access("NFPI"."ID"="SSI"."NFPI_ID"(+))
   6 - access("BPI"."ID"="NFPI"."BPI_ID"(+))
   7 - access("DPI"."ID"="BPI"."DPI_ID"(+))
   8 - access("DTI"."ID"="DPI"."TDL_ID"(+))
   9 - access("CD"."ID"="DTI"."CD_ID"(+))
  11 - filter("SA"."LONGITUDE" IS NOT NULL)
  12 - access(TO_NUMBER("LONGITUDE")>119.191148 AND TO_NUMBER("LATITUDE")>26.074423 AND
              TO_NUMBER("LONGITUDE")<119.197649 AND TO_NUMBER("LATITUDE")<26.077573)
       filter(TO_NUMBER("LONGITUDE") IS NOT NULL AND TO_NUMBER("LATITUDE")<26.077573 AND
              TO_NUMBER("LATITUDE")>26.074423)

這個執行計劃，看起來無比正常，應該要left join的都有。

但問題的關鍵在於10 步驟-- MERGE JOIN CARTESIAN。笛卡爾乘積的排序合併連接，這個需要耗費很長時間。

等待這個結果要耗費幾十秒，甚至要更久！
如何解決這樣的問題，有以下幾個方法：

  1. 重新收集每個表的統計數據--這個沒有實驗過，但即使那麼做，可能也無效。不過從本例看，很有可能是這個導致的。
  2. 啟用leading提示，結合其它提示
  3. 使用materialize提示

使用leading提示

1 select /*+ no_merge(a) no_push_pred(a) */
2  a.*
3   from (select
4         /*+ leading(cd dti dpi bpi ssi) */
5          ...) a
6  where a.longitude is not null
7 /

執行計劃

已選擇 12 行。


執行計劃
----------------------------------------------------------
Plan hash value: 1844304918

---------------------------------------------------------------------------------------------------------
| Id  | Operation                     | Name                    | Rows  | Bytes | Cost (%CPU)| Time  |
---------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT              |                         |     1 |   253 |   520   (2)| 00:00:07 |
|   1 |  TABLE ACCESS BY INDEX ROWID  | SCENE_BASE_INFO         |     1 |    14 |     1   (0)| 00:00:01 |
|*  2 |   INDEX UNIQUE SCAN           | SCENE_BASE_INFO_PK      |     1 |       |     0   (0)| 00:00:01 |
|   3 |  VIEW                         |                         |     1 |   253 |   520   (2)| 00:00:07 |
|*  4 |   HASH JOIN                   |                         |     1 |   251 |   520   (2)| 00:00:07 |
|*  5 |    TABLE ACCESS BY INDEX ROWID| SITE_ATTACHMENT         |     1 |    53 |    16   (0)| 00:00:01 |
|*  6 |     INDEX RANGE SCAN          | IDX_SITE_ATTACHMENT_JWD |     1 |       |    15   (0)| 00:00:01 |
|*  7 |    HASH JOIN RIGHT OUTER      |                         | 23606 |  4564K|   503   (2)| 00:00:07 |
|   8 |     TABLE ACCESS FULL         | SMALL_STATION_INFO      |   594 | 90882 |    13   (0)| 00:00:01 |
|*  9 |     HASH JOIN RIGHT OUTER     |                         | 15459 |   679K|   490   (2)| 00:00:06 |
|  10 |      TABLE ACCESS FULL        | NEAR_FAR_PLACE_INFO     |   389 |  3890 |     3   (0)| 00:00:01 |
|* 11 |      HASH JOIN RIGHT OUTER    |                         | 15459 |   528K|   486   (2)| 00:00:06 |
|  12 |       TABLE ACCESS FULL       | BUILDING_PLAN_INFO      |  3244 | 35684 |     8   (0)| 00:00:01 |
|* 13 |       HASH JOIN RIGHT OUTER   |                         | 15459 |   362K|   477   (1)| 00:00:06 |
|  14 |        TABLE ACCESS FULL      | DEMAND_PLAN_INFO        |  8787 | 96657 |   221   (1)| 00:00:03 |
|* 15 |        HASH JOIN OUTER        |                         | 15459 |   196K|   255   (1)| 00:00:04 |
|  16 |         INDEX FAST FULL SCAN  | PK_CONSOLIDATION_DEMAND |  6725 | 26900 |     5   (0)| 00:00:01 |
|  17 |         TABLE ACCESS FULL     | DEMAND_TEST_INFO        | 15459 |   135K|   249   (1)| 00:00:03 |
---------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("SBI"."ID"=:B1)
   4 - access("SA"."ATTACH_NAME"=SUBSTR("SSI"."AZIMUTH_ANGLE_PHOTO",INSTR("SSI"."AZIMUTH_ANGLE_PH
              OTO",'/',-1)+1,LENGTH("SSI"."AZIMUTH_ANGLE_PHOTO")))
   5 - filter("SA"."LONGITUDE" IS NOT NULL)
   6 - access(TO_NUMBER("LONGITUDE")>119.191148 AND TO_NUMBER("LATITUDE")>26.074423 AND
              TO_NUMBER("LONGITUDE")<119.197649 AND TO_NUMBER("LATITUDE")<26.077573)
       filter(TO_NUMBER("LONGITUDE") IS NOT NULL AND TO_NUMBER("LATITUDE")<26.077573 AND
              TO_NUMBER("LATITUDE")>26.074423)
   7 - access("NFPI"."ID"="SSI"."NFPI_ID"(+))
   9 - access("BPI"."ID"="NFPI"."BPI_ID"(+))
  11 - access("DPI"."ID"="BPI"."DPI_ID"(+))
  13 - access("DTI"."ID"="DPI"."TDL_ID"(+))
  15 - access("CD"."ID"="DTI"."CD_ID"(+))

沒有笛卡爾的merge join .步驟4還是一個hash join 。
執行很快，大概可以0.17秒

 

使用materialize提示

1  WITH A AS
2   (select /*+MATERIALIZE */
3     .....)
4  select a.* from A WHERE a.longitude is not null

執行計劃

已選擇 12 行。


執行計劃
----------------------------------------------------------
Plan hash value: 3536941173

--------------------------------------------------------------------------------------------------------------
| Id  | Operation                      | Name                        | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT               |                             | 23606 |  5832K|   700   (2)| 00:00:09 |
|   1 |  TEMP TABLE TRANSFORMATION     |                             |       |       |            |       |
|   2 |   LOAD AS SELECT               |                             |       |       |            |       |
|*  3 |    HASH JOIN RIGHT OUTER       |                             | 23606 |  5786K|   520   (2)| 00:00:07 |
|   4 |     TABLE ACCESS BY INDEX ROWID| SITE_ATTACHMENT             |     1 |    53 |    16   (0)| 00:00:01 |
|*  5 |      INDEX RANGE SCAN          | IDX_SITE_ATTACHMENT_JWD     |     1 |       |    15   (0)| 00:00:01 |
|*  6 |     HASH JOIN RIGHT OUTER      |                             | 23606 |  4564K|   503   (2)| 00:00:07 |
|   7 |      TABLE ACCESS FULL         | SMALL_STATION_INFO          |   594 | 90882 |    13   (0)| 00:00:01 |
|*  8 |      HASH JOIN RIGHT OUTER     |                             | 15459 |   679K|   490   (2)| 00:00:06 |
|   9 |       TABLE ACCESS FULL        | NEAR_FAR_PLACE_INFO         |   389 |  3890 |     3   (0)| 00:00:01 |
|* 10 |       HASH JOIN RIGHT OUTER    |                             | 15459 |   528K|   486   (2)| 00:00:06 |
|  11 |        TABLE ACCESS FULL       | BUILDING_PLAN_INFO          |  3244 | 35684 |     8   (0)| 00:00:01 |
|* 12 |        HASH JOIN RIGHT OUTER   |                             | 15459 |   362K|   477   (1)| 00:00:06 |
|  13 |         TABLE ACCESS FULL      | DEMAND_PLAN_INFO            |  8787 | 96657 |   221   (1)| 00:00:03 |
|* 14 |         HASH JOIN OUTER        |                             | 15459 |   196K|   255   (1)| 00:00:04 |
|  15 |          INDEX FAST FULL SCAN  | PK_CONSOLIDATION_DEMAND     |  6725 | 26900 |     5   (0)| 00:00:01 |
|  16 |          TABLE ACCESS FULL     | DEMAND_TEST_INFO            | 15459 |   135K|   249   (1)| 00:00:03 |
|* 17 |   VIEW                         |                             | 23606 |  5832K|   180   (2)| 00:00:03 |
|  18 |    TABLE ACCESS FULL           | SYS_TEMP_0FD9D68A2_721EF047 | 23606 |  4103K|   180   (2)| 00:00:03 |
--------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   3 - access("SA"."ATTACH_NAME"(+)=SUBSTR("SSI"."AZIMUTH_ANGLE_PHOTO",INSTR("SSI"."AZIMUTH_ANGLE_PHOT
              O",'/',-1)+1,LENGTH("SSI"."AZIMUTH_ANGLE_PHOTO")))
   5 - access(TO_NUMBER("LONGITUDE"(+))>119.191148 AND TO_NUMBER("LATITUDE"(+))>26.074423 AND
              TO_NUMBER("LONGITUDE"(+))<119.197649 AND TO_NUMBER("LATITUDE"(+))<26.077573)
       filter(TO_NUMBER("LONGITUDE"(+)) IS NOT NULL AND TO_NUMBER("LATITUDE"(+))<26.077573 AND
              TO_NUMBER("LATITUDE"(+))>26.074423)
   6 - access("NFPI"."ID"="SSI"."NFPI_ID"(+))
   8 - access("BPI"."ID"="NFPI"."BPI_ID"(+))
  10 - access("DPI"."ID"="BPI"."DPI_ID"(+))
  12 - access("DTI"."ID"="DPI"."TDL_ID"(+))
  14 - access("CD"."ID"="DTI"."CD_ID"(+))
  17 - filter("A"."LONGITUDE" IS NOT NULL)

也很快，大約0.19~0.2左右。
之所以慢，主要是因為要先生成gt表 SYS_TEMP_0FD9D68A2_721EF047。

 

總結

1.最好先收集統計數據

2.在收集統計數據無效的情況下，考慮使用leading提示，其次materialize提示也會破壞oracle優化器一些自以為明智的計劃（優化器的不足，oracle已經提到了，這就是hint的由來)

3.dba要優化一個庫，不是一個很容易的事情，需要做很多工作。

 


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • Android源碼博文集錦1
    Android精選源碼 Android優質博客 Kotlin編程中使用Glide v4 Generated API前期準備：在Gralde中引用Glide庫:dependencies {compile fileTree(include: , dir: 'libs')androidTestCompil ...
  • iOS多線程開發之GCD（中篇）
    前文回顧： 上篇博客講到GCD的實現是由隊列和任務兩部分組成，其中獲取隊列的方式有兩種，第一種是通過GCD的API的dispatch_queue_create函數生成Dispatch Queue；第二種是直接使用系統提供的標準Dispatch Queue ：Main Dispatch Queue和G ...
  • 掌握這些技能玩轉iOS
    近一年來，蘋果iOS/OS X頻繁被爆出重大安全漏洞，攻擊者可以通過漏洞竊取多達上千個應用的密碼。這些漏洞一旦被黑客掌握、利用，後果不堪設想。 好在這些漏洞的發現者還是有節操的，他們都將這些漏洞彙報給了蘋果公司，避免了重大損失的產生。不過，這也為廣大IOS用戶捏了一把冷汗。IOS並沒有想象中那麼安全 ...
  • Android程式員不容錯過的10款線上實用工具
    Android十款線上工具，在做Android 開發過程中,會遇到一些小的問題,雖然自己動手也能解決,但是有了一些小工具,解決這些問題就得心應手了。Android線上工具，包括線上測試工具，及其他較為重要的描述信息產品，希望能夠幫助大家更好的完成工作，減少不必要的錯誤發生。這款工具非常好用，下麵就由 ...
  • 極簡邏輯表達式的設計和查詢
    在資料庫開發中，對兩個關係表進行連接查詢，能夠直接做“邏輯或”的查詢，而對於邏輯與和邏輯非的查詢，則稍複雜點，需要編寫額外的代碼來實現。在關係型資料庫中，所謂的連接，實際上是集合的包含，只要包含一項，就滿足連接條件，實現的邏輯或，這種設計，能夠滿足絕大多數的查詢需求。有時，對於一條數據，可能需要通過 ...
  • 資料庫系統的基本組成內容
    資料庫系統的組成如下圖所示。 資料庫系統的硬體包括電腦的主機、鍵盤、顯示器和外圍設備(例如印表機、光碟機、磁帶機等)。由於一般資料庫系統所存放和處理的數據量很大，加之DBMS豐富的功能軟體，使得自身所占用的存儲空間很大，因此整個資料庫系統對硬體資源提出了較高的要求。這些要求是：①有足夠大的記憶體以存 ...
  • 通過SSIS的“查找”組件進行不同數據源之間數據的合併操作
    為了協助開發還原生產環境中的某些bug，需要將將生產環境的某些特定表數據導入到測試環境做測試，之前一直都是暴力地truncate測試環境的表，然後用SSIS將生產環境對應的整張表數據導入測試環境，簡便快捷後來開發提出來，保留測試環境已有的數據，只同步差異的數據（根據主鍵），於是就嘗試使用SSIS中的 ...
  • MySQL慢查詢日誌
    實驗環境：OS X EI Captian + MySQL 5.7一、配置MySQL自動記錄慢查詢日誌查看變數，也就是配置信息show (global) variables like '%slow_query%'修改變數：set global 變數名 = 值與慢查詢日誌有關的變數：是否開啟慢查詢日誌s... ...
一周排行
    -Advertisement-
    Play Games
  • 移動開發（一）：使用.NET MAUI開發第一個安卓APP
    移動開發（一）：使用.NET MAUI開發第一個安卓APP 對於工作多年的C#程式員來說，近來想嘗試開發一款安卓APP，考慮了很久最終選擇使用.NET MAUI這個微軟官方的框架來嘗試體驗開發安卓APP，畢竟是使用Visual Studio開發工具，使用起來也比較的順手，結合微軟官方的教程進行了安卓 ...
  • wpf ToggleButton選中效果和一個登錄界面
    前言 QuestPDF 是一個開源 .NET 庫，用於生成 PDF 文檔。使用了C# Fluent API方式可簡化開發、減少錯誤並提高工作效率。利用它可以輕鬆生成 PDF 報告、發票、導出文件等。 項目介紹 QuestPDF 是一個革命性的開源 .NET 庫，它徹底改變了我們生成 PDF 文檔的方 ...
  • 彈幕樹洞項目功能新增篇
    項目地址 項目後端地址： https://github.com/ZyPLJ/ZYTteeHole 項目前端頁面地址： ZyPLJ/TreeHoleVue (github.com) https://github.com/ZyPLJ/TreeHoleVue 目前項目測試訪問地址： http://tree ...
  • 第27篇 sqlserver2022詳細安裝步驟
    話不多說，直接開乾 一.下載 1.官方鏈接下載： https://www.microsoft.com/zh-cn/sql-server/sql-server-downloads 2.在下載目錄中找到下麵這個小的安裝包 SQL2022-SSEI-Dev.exe，運行開始下載SQL server； 二. ...
  • .NET 開源高性能 MQTT 類庫
    前言 隨著物聯網（IoT）技術的迅猛發展，MQTT（消息隊列遙測傳輸）協議憑藉其輕量級和高效性，已成為眾多物聯網應用的首選通信標準。 MQTTnet 作為一個高性能的 .NET 開源庫，為 .NET 平臺上的 MQTT 客戶端與伺服器開發提供了強大的支持。 本文將全面介紹 MQTTnet 的核心功能 ...
  • Serilog文檔翻譯系列（六） - 可用的接收器、增強器、格式化輸出
    Serilog支持多種接收器用於日誌存儲，增強器用於添加屬性，LogContext管理動態屬性，支持多種輸出格式包括純文本、JSON及ExpressionTemplate。還提供了自定義格式化選項，適用於不同需求。 ...
  • 警惕 Visual Studio 屬性求值副作用導致邏輯不符合預期
    目錄簡介獲取 HTML 文檔解析 HTML 文檔測試參考文章 簡介 動態內容網站使用 JavaScript 腳本動態檢索和渲染數據，爬取信息時需要模擬瀏覽器行為，否則獲取到的源碼基本是空的。 本文使用的爬取步驟如下： 使用 Selenium 獲取渲染後的 HTML 文檔 使用 HtmlAgility ...
  • [使用目前最新版]HybridCLR6.9.0+YooAsset2.2.4實現純C# Unity熱更新方案 (一)
    1.前言 什麼是熱更新 游戲或者軟體更新時，無需重新下載客戶端進行安裝，而是在應用程式啟動的情況下，在內部進行資源或者代碼更新 Unity目前常用熱更新解決方案 HybridCLR，Xlua，ILRuntime等 Unity目前常用資源管理解決方案 AssetBundles，Addressable， ...
  • 在 ASP.NET Core Web API 中使用操作篩選器統一處理通用操作
    本文章主要是在C# ASP.NET Core Web API框架實現向手機發送驗證碼簡訊功能。這裡我選擇是一個互億無線簡訊驗證碼平臺，其實像阿裡雲，騰訊雲上面也可以。 首先我們先去 互億無線 https://www.ihuyi.com/api/sms.html 去註冊一個賬號 註冊完成賬號後，它會送 ...
  • 第28篇 如何.net中實現高效可靠數據同步api
    通過以下方式可以高效，並保證數據同步的可靠性 1.API設計 使用RESTful設計，確保API端點明確，並使用適當的HTTP方法（如POST用於創建，PUT用於更新）。 設計清晰的請求和響應模型，以確保客戶端能夠理解預期格式。 2.數據驗證 在伺服器端進行嚴格的數據驗證，確保接收到的數據符合預期格 ...
所有分類