oracle 表关联索引优化,Oracle执行计划调优-超级大表关联超级小表的性能调优

今日客户现场出现一个查询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表数据量360万条;

customer表数据量76条;

0818b9ca8b590ca3270a3433284dd417.png

执行计划利用上了ACCTID索引,但是有大量的NESTED LOOPS,导致异常高的逻辑读。

将SQL中的AND openOrder2017.acctId IN ('##########')条件取消,SQL查询速度反而变快了,但是走的是全表扫描方式。

0818b9ca8b590ca3270a3433284dd417.png

突然醒悟,这是两个数据体量差距异常大的表,有严重的数据倾斜。通过openOrder2017.acctId索引访问,反而代价很大,择全表扫描的效率比选择索引要更高。

改造为:

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

WHERE  openOrder2017.orderTime >= 20170810000000

AND openOrder2017.orderTime <= 20170811235959

0818b9ca8b590ca3270a3433284dd417.png

执行计划虽然走了全表扫描,但是执行效率大幅提升了。

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值