今日客戶現(xiàn)場出現(xiàn)一個查詢SQL異常慢的情況。

用時分鐘級別。

SELECT *

FROM (SELECT a1.*, rownum rn

FROM (SELECT openOrder2017.exchId,

............

openOrder2017.internalbizmark,

customer.typeIdList

FROM openOrder2017, customer

WHERE openOrder2017.custId = customer.custId

AND openOrder2017.orderTime >= 20170810000000

AND openOrder2017.orderTime <= 20170811235959

AND openOrder2017.branchId IN ('001100', '001101')

AND openOrder2017.acctId IN ('##########')

AND openOrder2017.optLevel IN ('A0')

AND openOrder2017.custType IN

('A2', 'A9', 'A1', 'A4', 'A3')

ORDER BY orderTime, serialNum) a1

WHERE rownum <= 100) a2

WHERE rn >= 1;

其中：

openOrder2017表數(shù)據(jù)量360萬條；

customer表數(shù)據(jù)量76條；

執(zhí)行計劃利用上了ACCTID索引，但是有大量的NESTED LOOPS，導(dǎo)致異常高的邏輯讀。

將SQL中的AND openOrder2017.acctId IN ('##########')條件取消，SQL查詢速度反而變快了，但是走的是全表掃描方式。

突然醒悟，這是兩個數(shù)據(jù)體量差距異常大的表，有嚴重的數(shù)據(jù)傾斜。通過openOrder2017.acctId索引訪問，反而代價很大，擇全表掃描的效率比選擇索引要更高。

改造為：

FROM ?openOrder2017 left join customer ?on openOrder2017.custId = customer.custId

WHERE ?openOrder2017.orderTime >= 20170810000000

AND openOrder2017.orderTime <= 20170811235959

執(zhí)行計劃雖然走了全表掃描，但是執(zhí)行效率大幅提升了。

總結(jié)

以上是生活随笔為你收集整理的oracle 表关联索引优化,Oracle执行计划调优-超级大表关联超级小表的性能调优的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。