在數據庫應用中，SQL 性能至關重要。低效 SQL 常致系統響應遲緩，而優化能顯著提速。
本案例中的SQL 來源于某客戶業務系統中的核心查詢語句，為嚴格遵循數據安全與隱私保護原則，已對涉及客戶敏感信息的表名、字段名以及數據值等進行脫敏處理。
下面列出我們發現的特定模塊中Top SQL的相關情況：
1. SQL_ID:7ts08a2d6qbgb
1）SQL文本
這條SQL超過了700行，截取關鍵部分分析
UPDATE TBL_XX_HEADER TEST SET (TEST.COL_SUM, TEST.COL_BEGIN, TEST.COL_PERIOD, TEST.COL_INCOMING, TEST.COL_END, TEST.COL_UPD_DATE, TEST.COL_UPD_BY) = (SELECT SUM(LN.COL_SUM), SUM(LN.COL_BEGIN), SUM(LN.COL_PERIOD), SUM(LN.COL_INCOMING), SUM(LN.COL_END), SYSDATE, FND_GLOBAL.USER_ID FROM CUX.TBL_XX_LINES LN WHERE LN.KEY_1 = TEST.KEY_1 AND LN.COL_PERIOD = TEST.COL_PERIOD AND LN.ORG_ID = TEST.ORG_ID AND (LN.ATTR_1 IS NULL OR LN.ATTR_1 IN ('產品1', '產品2', '產品3')) GROUP BY LN.KEY_1, LN.COL_PERIOD) WHERE TEST.ORG_ID = 5565 AND TEST.ORGANIZATION_ID = 5561 AND TEST.COL_PERIOD = '2021-10' AND TEST.KEY_1 < 0;
2）SQL執行計劃
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop || 0 | UPDATE STATEMENT | | | | 68 (100)| | | || 1 | UPDATE | TBL_XX_HEADER | | | | | | ||* 2 | INDEX RANGE SCAN | IDX_XX_01 | 3 | 183 | 4 (0)| 00:00:01 | | || 3 | SORT GROUP BY NOSORT | | 1 | 94 | 2 (0)| 00:00:01 | | || 4 | PARTITION RANGE SINGLE | | 1 | 94 | 2 (0)| 00:00:01 | KEY | KEY ||* 5 | TABLE ACCESS STORAGE FULL| TBL_XX_LINES | 1 | 94 | 2 (0)| 00:00:01 | KEY | KEY |Predicate Information (identified by operation id):2 - access("TEST"."ORG_ID"=:B3 AND "TEST"."COL_PERIOD"=:B1 AND "TEST"."ORGANIZATION_ID"=:B2 AND "TEST"."KEY_1"<0)5 - filter(("LN"."KEY_1"=:B1 AND "LN"."COL_PERIOD"=:B2 AND "LN"."ORG_ID"=:B3 AND ("LN"."ATTR_1" IS NULL OR INTERNAL_FUNCTION("LN"."ATTR_1"))))
3）SQL資源消耗
PLAN CHI USER CPU(MS) ELA(MS) DISK GET ROWS ROWS APPLI(MS) CONCUR(MS) CLUSTER(MS) USER_IO(MS) FIRST_LOAD_TIME EXEC HASH VALUE NUM NAME PRE EXEC PRE EXEC PRE EXEC PRE EXEC PRE EXEC PRE FETCH PER EXEC PER EXEC PER EXEC PER EXEC LAST_LOAD_TIME 0 918035873 0 APPS 3,511,121 3,712,412 1,713 434,385,844 0 0 0 4 885 582 11-01/15:3.11-01/15:3
該SQ修改數據在20000條數據，近期未執行成功。
通過分析SQL文本，發現該SQL為update類型。
通過分析執行計劃，TBL_XX_LINES作為NL被驅動表走全表掃描，而該表的體積近2GB，這就導致該SQL執行效率非常低。
結合以上分析，該SQL創建合適的索引即可優化。
1. 創建組合索引
CREATE INDEX CUX.IDX_XX_04 ON CUX.TBL_XX_LINES(ORG_ID,KEY_1,COL_PERIOD,ATTR_1)ONLINE PARALLEL 16;ALTER INDEX CUX.IDX_XX_04 NOPARALLEL;
通過確認關鍵表數據量，制定執行計劃，可以減少每次查詢的邏輯讀和物理讀，提高SQL執行性能。
SQL 優化看似細枝末節，實則關乎系統性能與數據效率的根基。
每一個慢查詢的背后，往往隱藏著數據結構、業務邏輯與執行計劃之間的微妙博弈。
我們希望通過這一系列實際案例的拆解，幫助你在實戰中掌握優化思路與方法論。
閱讀原文：原文鏈接
該文章在 2025/6/23 12:53:37 編輯過
400 186 1886
