這篇文章給大家分享的是有關如何提高SQL性能的內容。小編覺得挺實用的,因此分享給大家做個參考,一起跟隨小編過來看看吧。
1 該最開始的 sql 執行情況如下
SQL> SELECT 2 NVL(T.RELA_OFFER_SPEC_ID, SUBOS.SUB_OFFER_SPEC_ID) "offerSpecId" 3 FROM OFFER_SPEC_RELA T 4 LEFT JOIN OFFER_SPEC_GRP_RELA SUBOS 5 ON T.RELA_GRP_ID = SUBOS.OFFER_SPEC_GRP_ID 6 AND subos.start_dt <= SYSDATE 7 AND subos.end_dt >= SYSDATE 8 WHERE T.RELA_TYPE_CD = 2 9 AND t.start_dt <= SYSDATE 10 AND t.end_dt >= SYSDATE 11 AND (T.OFFER_SPEC_ID = 109910000618 12 OR EXISTS 13 (SELECT A.OFFER_SPEC_GRP_ID 14 FROM OFFER_SPEC_GRP_RELA A 15 WHERE A.SUB_OFFER_SPEC_ID = 109910000618 16 AND T.OFFER_SPEC_GRP_ID = A.OFFER_SPEC_GRP_ID 17 )) 18 AND rownum<500; no rows selected Execution Plan ---------------------------------------------------------- Plan hash value: 1350156609

Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter(ROWNUM<500)
2 - filter("T"."OFFER_SPEC_ID"=109910000618 OR EXISTS (SELECT 0 FROM
"SPEC"."OFFER_SPEC_GRP_RELA" "A" WHERE "A"."OFFER_SPEC_GRP_ID"=:B1 AND
"A"."SUB_OFFER_SPEC_ID"=109910000618))
3 - access("T"."RELA_GRP_ID"="SUBOS"."OFFER_SPEC_GRP_ID"(+))
4 - filter("T"."RELA_TYPE_CD"=2 AND "T"."END_DT">=SYSDATE@! AND
"T"."START_DT"<=SYSDATE@!)
5 - filter("SUBOS"."END_DT"(+)>=SYSDATE@! AND "SUBOS"."START_DT"(+)<=SYSDATE@!)
6 - access("A"."SUB_OFFER_SPEC_ID"=109910000618 AND "A"."OFFER_SPEC_GRP_ID"=:B1)
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
12444 consistent gets
0 physical reads
0 redo size
339 bytes sent via SQL*Net to client
509 bytes received via SQL*Net from client
1 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
0 rows processed
PLAN GET DISK WRITE ROWS ROWS USER_IO(MS) ELA(MS) CPU(MS) CLUSTER(MS) PLSQL
END_TI I HASH VALUE EXEC PRE EXEC PRE EXEC PER EXEC ROW_P PRE EXEC PRE FETCH PER EXEC PRE EXEC PRE EXEC PER EXEC PER EXEC
2 第一次分析
此時應該有以下個地方值得注意
1) 該 sql 每天執行上千次,平均每次執行返回不到 10 行數據,但是平均邏輯讀達到1.2W,可能存在性能問題。
2)ID 為 4,5 的執行計劃路徑中出現了兩個全表掃描,看到這兒我們可以想到可能是沒有合適的索引導致走了全表掃描從而執行效率低下。
3)ID 為 2 的執行計劃路徑出現了 FILTER,且 3,和 6 為其子路徑,如果FILTER有兩個及兩個以上的子路徑,那么他的執行原理將類似于嵌套循環,id 號最小的子路徑如果返回行數較多,可能會導致多次執行id號更小的子路徑,導致性能低下。一般存在 “OR EXISTS” 的時候會出現此情況,可以根據情況避免。
感謝各位的閱讀!關于“如何提高SQL性能”這篇文章就分享到這里了,希望以上內容可以對大家有一定的幫助,讓大家可以學到更多知識,如果覺得文章不錯,可以把它分享出去讓更多的人看到吧!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。