在數(shù)據(jù)庫應用中，SQL 性能至關重要。低效 SQL 常致系統(tǒng)響應遲緩，而優(yōu)化能顯著提速。
本案例中的SQL 來源于某客戶業(yè)務系統(tǒng)中的核心查詢語句，為嚴格遵循數(shù)據(jù)安全與隱私保護原則，已對涉及客戶敏感信息的表名、字段名以及數(shù)據(jù)值等進行脫敏處理。
下面列出我們發(fā)現(xiàn)的特定模塊中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執(zhí)行計劃
| 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修改數(shù)據(jù)在20000條數(shù)據(jù)，近期未執(zhí)行成功。
通過分析SQL文本，發(fā)現(xiàn)該SQL為update類型。
通過分析執(zhí)行計劃，TBL_XX_LINES作為NL被驅動表走全表掃描，而該表的體積近2GB，這就導致該SQL執(zhí)行效率非常低。
結合以上分析，該SQL創(chuàng)建合適的索引即可優(yōu)化。
1. 創(chuàng)建組合索引
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;
通過確認關鍵表數(shù)據(jù)量，制定執(zhí)行計劃，可以減少每次查詢的邏輯讀和物理讀，提高SQL執(zhí)行性能。
SQL 優(yōu)化看似細枝末節(jié)，實則關乎系統(tǒng)性能與數(shù)據(jù)效率的根基。
每一個慢查詢的背后，往往隱藏著數(shù)據(jù)結構、業(yè)務邏輯與執(zhí)行計劃之間的微妙博弈。
我們希望通過這一系列實際案例的拆解，幫助你在實戰(zhàn)中掌握優(yōu)化思路與方法論。
閱讀原文：原文鏈接
該文章在 2025/6/23 12:53:37 編輯過
400 186 1886
