我常常会听到一些同事对自己的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执行计划和成本估算(如下图)
注意画框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计划和预算成本:
执行成本大幅降低。INDEX的建立时索引字段排序的方式其实对特定SQL影响还是很大的。尤其是一些历史流水表，在某些情况下只是查询近期的数据时，就显得尤为重要了。
注：文中的SQL因为某些问题，我做了适当的处理，在显示的执行计划图中也是处理过的，所以会出现表名不十分匹配的问题，请大家见谅。
PS:
最近总是很忙，忙的只有在睡觉前才有时间写点东西。但是实在太累，总是无法好好的写。真的要好好坚持坚持呀 -:)，否则年初的目标就很难完成了。
本文转自Be the miracle!博客51CTO博客，原文链接http://blog.51cto.com/miracle/169244如需转载请自行联系原作者
Larry.Yue
