2. 程式人生 > >樹形查詢SQL優化一例

樹形查詢SQL優化一例

阿新 • • 發佈：2019-01-27
SELECT COUNT(1) FROM (select m.sheet_id from cpm_main_sheet_history m, cpm_service_warn_config s where m.sheet_type_id in (select /*+ connect_by_filtering */ t.row_id from tbl_class_trees t start with t.row_id = s.sheet_type_id connect
by t.parent_row_id = prior t.row_id) and m.service_type in (select /*+ connect_by_filtering */ tt.row_id from tbl_class_trees tt start with tt.row_id = s.business_type_id connect by tt.parent_row_id = prior tt.row_id) and
m.accept_time >= TO_CHAR(SYSDATE - time_interval / 24, 'yyyy-mm-dd hh24:mi:ss') and s.row_id = 'AS170904165251' and m.no_area in ('0000')) c__ PLAN_TABLE_OUTPUT Plan hash value: 2824841339 ---------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows
| Bytes | Cost (%CPU)| Time | ---------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 246 | 188K (1)| 00:37:47 | |* 1 | FILTER | | | | | | | 2 | NESTED LOOPS | | 3021 | 725K| 816 (1)| 00:00:10 | | 3 | TABLE ACCESS BY INDEX ROWID | CPM_SERVICE_WARN_CONFIG | 1 | 106 | 1 (0)| 00:00:01 | |* 4 | INDEX UNIQUE SCAN | PK_CONFIG_ROW_ID | 1 | | 0 (0)| 00:00:01 | | 5 | TABLE ACCESS BY INDEX ROWID | CPM_MAIN_SHEET_HISTORY | 3021 | 413K| 815 (1)| 00:00:10 | |* 6 | INDEX RANGE SCAN | IDX_CPM_NO_AREA_TIME1 | 563 | | 136 (0)| 00:00:02 | |* 7 | FILTER | | | | | | |* 8 | CONNECT BY WITH FILTERING | | | | | | | 9 | TABLE ACCESS BY INDEX ROWID| TBL_CLASS_TREES | 1 | 107 | 2 (0)| 00:00:01 | |* 10 | INDEX UNIQUE SCAN | PK_TBL_CLASS_TREESS | 1 | | 1 (0)| 00:00:01 | |* 11 | HASH JOIN | | | | | | | 12 | CONNECT BY PUMP | | | | | | | 13 | TABLE ACCESS FULL | TBL_CLASS_TREES | 6 | 318 | 113 (0)| 00:00:02 | |* 14 | FILTER | | | | | | |* 15 | CONNECT BY WITH FILTERING | | | | | | | 16 | TABLE ACCESS BY INDEX ROWID| TBL_CLASS_TREES | 1 | 107 | 2 (0)| 00:00:01 | |* 17 | INDEX UNIQUE SCAN | PK_TBL_CLASS_TREESS | 1 | | 1 (0)| 00:00:01 | |* 18 | HASH JOIN | | | | | | | 19 | CONNECT BY PUMP | | | | | | | 20 | TABLE ACCESS FULL | TBL_CLASS_TREES | 6 | 318 | 113 (0)| 00:00:02 | ---------------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter( EXISTS (SELECT /*+ CONNECT_BY_FILTERING */ 0 FROM "TBL_CLASS_TREES" "T" WHERE "T"."ROW_ID"=:B1 START WITH "T"."ROW_ID"=:B2) AND EXISTS (SELECT /*+ CONNECT_BY_FILTERING */ 0 FROM "TBL_CLASS_TREES" "TT" WHERE "TT"."ROW_ID"=:B3 START WITH "TT"."ROW_ID"=:B4)) 4 - access("S"."ROW_ID"='AS170904165251') 6 - access("M"."ACCEPT_TIME">=TO_CHAR([email protected]!-"TIME_INTERVAL"/24,'yyyy-mm-dd hh24:mi:ss') AND "M"."NO_AREA"='0000' AND "M"."ACCEPT_TIME" IS NOT NULL) filter("M"."NO_AREA"='0000') 7 - filter("T"."ROW_ID"=:B1) 8 - access("T"."PARENT_ROW_ID"=PRIOR "T"."ROW_ID") 10 - access("T"."ROW_ID"=:B1) 11 - access("T"."PARENT_ROW_ID"=PRIOR "T"."ROW_ID") 14 - filter("TT"."ROW_ID"=:B1) 15 - access("TT"."PARENT_ROW_ID"=PRIOR "TT"."ROW_ID") 17 - access("TT"."ROW_ID"=:B1) 18 - access("TT"."PARENT_ROW_ID"=PRIOR "TT"."ROW_ID") --優化後，SQL能在5s返回結果

相關推薦

樹形查詢SQL優化一例

SELECT COUNT(1) FROM (select m.sheet_id from cpm_main_sheet_history m, cpm_service_warn_config s where m.sheet_type_id in

常用SQL優化(一)，提升運算效率

大數據 必須 -name 過大 一半 一次 存儲過程 是否 ins 網上關於SQL優化的教程很多，但是比較雜亂。近日有空整理了一下，寫出來跟大家分享一下，其中有錯誤和不足的地方，還請大家糾正補充。1.對查詢進行優化，應盡量避免全表掃描，首先應考慮在 where 及 orde

sql優化(一)

---title: sql語句的優化（一）date: 2018-10-20categories: 資料庫優化--- # Explain 命令 資料庫查詢效率的快慢往往是評價一個數據庫是好是差其中的一個標準。 對於好的資料庫而言，往往離不開良好的資料庫設計，硬體配置，網路等諸多因數。 那麼我們在日常開發

【Altera部落格大賽】時序優化一例（三）

在使用兩種方法（《時序優化一例（一）》，《時序優化一例（二）》）對設計進行時序優化後，設計的建立時間餘量從-1.070優化到-0.240，但是時序還未達到收斂，繼而嘗試了許多其它方法：     （一）區域性優化    &n

oracle查詢SQL優化

如果表中的時間欄位是索引，那麼時間欄位不要使用函式，函式會使索引失效。 例如： select * from mytable where trunc(createtime)=trunc(sysdate);--不走索引,慢吞吞。createtime欄位有時分秒，使用trunc(）函式去除時分秒，只保留年

Oracle效能優化之高階SQL優化(一)

  使用基於規則的優化器（CBO）時，Oracle解析器按照從右到左的順序處理FROM子句的表明，即FROM子句中最後的表（驅動表）會最先被處理。   當FROM子句包含多個表時，建議將記錄最少的表（一般是字典表）放在最後面。當Oracle處理多個表時，一般採用排序或合併的方式連線這些表，系統首先會掃描FR

PostgreSQL查詢優化：查詢條件優化一(條件分類)

在SQL中，查詢條件在查詢優化階段需要被分成三種類型，三類條件有不同的作用，在某些情況下，可以相互轉化。 首先說明一下SQL語句的執行步驟，可以分為三步：一，讀取表中的元組；二，如果有JOIN，則開始做JOIN；三，針對WHERE條件作過濾。我們以簡單的SQL為例： 表TB

高階SQL優化(一) ——《12年資深DBA教你Oracle開發與優化——效能優化部分》

  使用基於規則的優化器（CBO）時，Oracle解析器按照從右到左的順序處理FROM子句的表明，即FROM子句中最後的表（驅動表）會最先被處理。   當FROM子句包含多個表時，建議將記錄最少的表（一般是字典表）放在最後面。當Oracle處理多個表時，一般採用排序或合併的方式連線這些表，系統首先會掃描FR

Oracle AWR性能優化一例

並且 完全 采樣 rep 24小時 segment 就是 session 實例 有一個批處理程序運行超過24小時仍然不能完成，采集了程序運行期間的AWR報告如下。 由上可以看到，該系統為AIX的單實例數據庫，采樣時長1319.96 分鐘，DB time 1532.15分鐘。

結合innodb的B+樹索引來優化sql查詢一例

先上表結構： CREATE TABLE `quote_xxxxx` ( `instrument_id` varchar(20) NOT NULL, `time_type` varchar(20)

SQL Server 查詢效能優化——建立索引原則（一）

 索引是什麼？索引是提高查詢效能的一個重要工具，索引就是把查詢語句所需要的少量資料新增到索引分頁中，這樣訪問資料時只要訪問少數索引的分頁就可以。但是索引對於提高查詢效能也不是萬能的，也不是建立越多的索引就越好。索引建少了，用WHERE子句找資料效率低，不利於查詢資料。索引建多

Sql server 2008查詢效能優化學習筆記一

一、在調整過程中，必須檢查各種可能影響基於Sqlserver的應用程式效能的硬體和軟體因素。你應該在效能分析中問自己以下的問題： 1.相同伺服器上有沒有執行其他的資源密集型應用？ 2.硬體子系統是否能承受最大的工作負荷？ 3.Sql server 是否被正確配置？ 4.Sq

mysql通過將or改成union來優化sql效能問題一例

某系統測試環境有支SQL執行時間較長，開發人員請求dba協助優化。 原SQL如下： SELECT   g.id,           ----省略-----     FROM    g,             y,             t,             o

ArcGIS 空間查詢一例

rec services 開發 .sh tle eas get ask 關系 ISpatialFilter spatialFilter = new SpatialFilterClass(); spatialFilter.Geometry = Po

SQL優化-子查詢&case&limit

子查詢優化load 導數據.notesdxtdb 數據庫 total_time 475.60秒。 監控服務：倉頡select t_.*, a.name acquirer_name,m.merchant_name, am.merchant_name acq_merchant_name,

崔華基於oracle的SQL優化讀書筆記（一）如何得到真實的執行計劃

hash mes getting binary oracl only 中文 fun roc ---恢復內容開始--- 得到目標SQL的執行計劃，大致有以下四種方式： 1.explain plan 命令 2.DBMS_XPLAN包 3.SQLPLUS中的autotrace開關

SQL多表連接查詢（詳細實例）

需要 笛卡爾 null 情況 查詢 比較運算符 連接查詢 right -1 本文主要列舉兩張和三張表來講述多表連接查詢。 新建兩張表： 表1：student 截圖如下： 表2：course 截圖如下： （此時這樣建表只是為了演示連接SQL語句，當然實際開發中我們不會這

SQL數據查詢語句（一）

delete 紅色 cnblogs col mage 列名 http font 根據 本文所用數據庫為db_Test，數據表為Employee 一.SELECT語句基本結構 語句語法簡單歸納為： SELECT select_list [INTO new_table_name

轉://從一條巨慢SQL看基於Oracle的SQL優化

查看 針對性 map 分區 有關 需要 fix pts 大局觀 http://mp.weixin.qq.com/s/DkIPwbDKIjH2FMN13GkT4w 本次分享的內容是基於Oracle的SQL優化，以一條巨慢的SQL為例，從快速解讀SQL執行計劃、如何從執行計劃中

MySql5.5 SQL優化 慢查詢日誌存儲

dumps log_file 路徑 home mysql 索引 格式 ont 設置 一、MySql的慢查詢日誌的開啟和存儲 1、查看是否把沒有使用索引的SQL記錄到慢查詢日誌中，查看 log_queries_not_using_indexes 變量; show VARIA