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