【性能优化案例】执行计划宁可走全表扫描,也不走索引

本文通过一个性能优化案例,展示了当执行计划选择全表扫描而非索引时的原因。在对名为TABLE1的表进行查询时,尽管存在SEQ_ORD列上的非唯一索引NONUNI_INDEX,但初始执行计划选择了全表扫描。分析发现,高聚簇因子导致索引使用效率低下,增加额外成本。通过重建索引,降低了聚簇因子,从而显著提升了查询性能。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

准备信息:

表:TABLE1,有一列为SEQ_ORD。

索引:在SEQ_ORD列上有一个NORMAL索引NONUNI_INDEX【nonunique】

 

问题:

测试语句:

SELECT SUM(SEQ_ORD) FROM TABLE1 WHERE SEQ_ORD>100;

第一次运行的时候,发现执行计划走的是全表扫描,并没有走索引。执行计划如下图:

 

 

于是,我在语句中添加了/*+INDEX(TABLE1 NONUNI_INDEX)*/的提示,让优化器能够走索引。执行计划如下图:<

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值