oracle TABLE ACCESS BY INDEX ROWID 你不知道的索引回表-开发系列(三)

本文介绍了一个关于SQL查询效率的问题及解决方案。通过对不同SQL语句执行计划的对比分析,揭示了使用COUNT(*)相较于COUNT(列名)在特定场景下更快的原因,并提出了有效的优化策略。

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

1 引言


近期系统常常提示一个sql查询时间过长的问题,看了一下就是一个每天依照时间戳统计前一天量的sql。
表总的数据量为53483065。

语句例如以下:

select count(x.serial_id) as countnum
  from iodso.qos_cnst_busilog_td x
 where x.oper_time between trunc(sysdate- 1) and trunc(sysdate);



运行时间情况例如以下:(运行要49s)




看了下运行计划 是这种:




 从上面的运行计划来看 也是走了索引的 是索引范围扫描。


2 解决

搞不明确 ,决定用count(*) 试试。

运行时间情况例如以下:


时间非常快,1s不到。

区别非常大,感觉非常奇怪 就比較了一下 两者的运行计划。以下是count(*)的运行计划


 

 

对照了下 发现 慢的那个 多了个 TABLE ACCESS BY INDEX ROWID。


3 结论

得出原因:索引有一个单独的块存储,依据oper_time 统计表的数据量时 仅仅须要在索引的块里面统计数据量就能够了,所以比較快。

那个count(serialid) :

Oracle 索引中保存的是我们字段的值和该值相应的rowid。我们依据索引进行查找,索引范围扫描后。就会返回该block的rowid,然后依据rowid直接去block上去我们须要的数据,因此就出现了:TABLE ACCESS BY INDEX ROWID

由于还要依据rowid回表的数据块上查询数据。所以速度慢了非常多。



4 备注:

以下两个查询的运行时间也非常快,由于运行计划与count(*)都是一样的。


select COUNT(x.oper_time) AS countnum

  fromiodso.qos_cnst_busilog_td x

 where x.oper_timebetween trunc(sysdate - 1) and trunc(sysdate);

 

 

 

select COUNT(1) AS countnum

  fromiodso.qos_cnst_busilog_td x

 where x.oper_timebetween trunc(sysdate - 1) and trunc(sysdate);


 

 

 



 


评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值