我常常会听到一些同事对自己的SQL很有信心,往往说一句:“你看,已经走索引了”。但是我们真的使用了适合我们的索引吗?
我抓取到一句SQL,消耗了太多的IO。
因为TBL_WAPXXX数据量比较大,而造成该SQL执行缓慢并且IO消耗高。看看它的SQL执行计划和成本估算(如下图)
注意画框INDEX(为TBL_WAPXXX的相关索引),虽然走了索引,但是成本和cardnility都很高。检查这个索引发现其实BLEVEL只有2。而再仔细查看SQL并询问实现的功能,其实索引的字段为DATE类型,该SQL只是检查最近几个小时的信息变化.
在WHERE条件中(WARE_DATE > :B2)因为是范围查询,索引使用了(rang scan),加之该表数据量众多(千万级别),直接影响了SQL执行性能。
但是通过检查发现,这个索引就是直接创建的B-TREE索引。而我注意到其实该SQL检查的就是最近一个或几个小时的数据,终于可以找到一些问题所在了。INDEX建立时默认情况下,索引的字段采用升序(asc)建立,而这种方法显然是不适合当前这个SQL的,我们可以通过建立基于降序的索引来适应实际的需求。
再来检查执行的SQL计划和预算成本:
执行成本大幅降低。INDEX的建立时索引字段排序的方式其实对特定SQL影响还是很大的。尤其是一些历史流水表,在某些情况下只是查询近期的数据时,就显得尤为重要了。
注:文中的SQL因为某些问题,我做了适当的处理,在显示的执行计划图中也是处理过的,所以会出现表名不十分匹配的问题,请大家见谅。
PS:
最近总是很忙,忙的只有在睡觉前才有时间写点东西。但是实在太累,总是无法好好的写。真的要好好坚持坚持呀 -:),否则年初的目标就很难完成了。
我抓取到一句SQL,消耗了太多的IO。
select SMIN_INFOID,NVL(MI.MONU_PROVINCE,
'未知'),
COUNT(*) I_RESULTNUM
FROM TBL_WAPXXX WARE,TBL_SMSXXX SMIN,TBL_MOBILEXXX MI,TBL_USERXXX USIN
WHERE WARE_DATE > :B2 AND WARE_DATE <= :B2 + :B1 /24
AND WARE.WARE_UID_FK=USIN.USIN_UID_FK AND SUBSTR(USIN.USIN_PHNUM,1,7)=MI.MONU_PHONENUM(+)
AND WARE_WRUIID_FK=SMIN.SMIN_INFOID GROUP BY SMIN_INFOID ,MI.MONU_PROVINCE
FROM TBL_WAPXXX WARE,TBL_SMSXXX SMIN,TBL_MOBILEXXX MI,TBL_USERXXX USIN
WHERE WARE_DATE > :B2 AND WARE_DATE <= :B2 + :B1 /24
AND WARE.WARE_UID_FK=USIN.USIN_UID_FK AND SUBSTR(USIN.USIN_PHNUM,1,7)=MI.MONU_PHONENUM(+)
AND WARE_WRUIID_FK=SMIN.SMIN_INFOID GROUP BY SMIN_INFOID ,MI.MONU_PROVINCE
因为TBL_WAPXXX数据量比较大,而造成该SQL执行缓慢并且IO消耗高。看看它的SQL执行计划和成本估算(如下图)
![](../attachment/200906/200906231245769549852.jpg)
注意画框INDEX(为TBL_WAPXXX的相关索引),虽然走了索引,但是成本和cardnility都很高。检查这个索引发现其实BLEVEL只有2。而再仔细查看SQL并询问实现的功能,其实索引的字段为DATE类型,该SQL只是检查最近几个小时的信息变化.
在WHERE条件中(WARE_DATE > :B2)因为是范围查询,索引使用了(rang scan),加之该表数据量众多(千万级别),直接影响了SQL执行性能。
但是通过检查发现,这个索引就是直接创建的B-TREE索引。而我注意到其实该SQL检查的就是最近一个或几个小时的数据,终于可以找到一些问题所在了。INDEX建立时默认情况下,索引的字段采用升序(asc)建立,而这种方法显然是不适合当前这个SQL的,我们可以通过建立基于降序的索引来适应实际的需求。
SQL>
create
index IDX_WARE_DATE1
on TBL_WAPXXXX(WARE_DATE
desc)
2 tablespace USERTBS;
2 tablespace USERTBS;
再来检查执行的SQL计划和预算成本:
![](../attachment/200906/200906231245770796316.jpg)
执行成本大幅降低。INDEX的建立时索引字段排序的方式其实对特定SQL影响还是很大的。尤其是一些历史流水表,在某些情况下只是查询近期的数据时,就显得尤为重要了。
注:文中的SQL因为某些问题,我做了适当的处理,在显示的执行计划图中也是处理过的,所以会出现表名不十分匹配的问题,请大家见谅。
PS:
最近总是很忙,忙的只有在睡觉前才有时间写点东西。但是实在太累,总是无法好好的写。真的要好好坚持坚持呀 -:),否则年初的目标就很难完成了。