INDEX建立方式对SQL的影响

爱死你了

我常常会听到一些同事对自己的SQL很有信心，往往说一句：“你看，已经走索引了”。但是我们真的使用了适合我们的索引吗？　　我抓取到一句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)因为是范围查询,索引使用了(rang scan)，加之该表数据量众多(千万级别)，直接影响了SQL执行性能。
　　但是通过检查发现，这个索引就是直接创建的B-TREE索引。而我注意到其实该SQL检查的就是最近一个或几个小时的数据，终于可以找到一些问题所在了。INDEX建立时默认情况下，索引的字段采用升序(asc)建立，而这种方法显然是不适合当前这个SQL的，我们可以通过建立基于降序的索引来适应实际的需求。
SQL> create index>    2        tablespace USERTBS;　　再来检查执行的SQL计划和预算成本:

http://blog.51cto.com/miracle/../attachment/200906/200906231245770796316.jpg

　　执行成本大幅降低。INDEX的建立时索引字段排序的方式其实对特定SQL影响还是很大的。尤其是一些历史流水表，在某些情况下只是查询近期的数据时，就显得尤为重要了。
　　注：文中的SQL因为某些问题，我做了适当的处理，在显示的执行计划图中也是处理过的，所以会出现表名不十分匹配的问题，请大家见谅。
　　PS:
　　最近总是很忙，忙的只有在睡觉前才有时间写点东西。但是实在太累，总是无法好好的写。真的要好好坚持坚持呀 -:)，否则年初的目标就很难完成了。