飄ぺ風
【宁可因梦想而忙碌,不要因忙碌而失去梦想】

转自:http://jingyan.baidu.com/article/8275fc868ce57946a03cf692.html

 

一条sql突然执行变慢,耗时9秒,应用是不能改的,只能从数据库方面下手解决

步骤思路:

1:查看sql是否走索引

2:查看索引是否失效

3:hint 强制走索引(只是用来查看hint状态下,查询是否更改,应用是不能改的)

4:收集该表所有信息(包括索引)

5:分析该表所有信息(包括索引)

6:再次执行并查看

注意:哪个用户执行较慢,就用哪个用户进行操作,这样才准确

 

方法/步骤

  1. 查看sql是否走索引

     

    以下是突然查询较慢的sql语句:

    select * from  wwff 

    where JGSJ>=to_date('2014-10-26 00:00:00','yyyy-mm-dd HH24:Mi:SS')

    and SJZT=1 and  FJBJ=3 and FJR=1 and rownum <= 1

    耗时 9秒

    注释:在JGSJ 字段上已经创建了索引,查看执行计划,发现表没有走索引,进行全表扫描

     

  2. 查看索引是否失效

     

    select 'alter index '||a.owner||'.'||a.index_name||' rebuild nologging online;'

    from dba_indexes a

    where a.table_name='WWFF'

    and a.status<>'VALID'

    and a.partitioned<>'YES';  --因为该表不是分区表

     

     

  3. hint 强制走索引(只是用来查看hint状态下,查询是否更改,应用是不能改的)

     

    select /*+index(wwff IDX$$_wwff_JGSJ)*/ * from  wwff 

    where JGSJ>=to_date('2014-10-26 00:00:00','yyyy-mm-dd HH24:Mi:SS')

    and SJZT=1 and  FJBJ=3 and FJR=1 and rownum <= 1

    耗时0.03秒

    强制走索引之后,耗时才0.03秒,所以必须让该查询较慢的sql走上索引

     

  4. 收集该表所有信息(包括索引)

     

    SQL> exec dbms_stats.gather_table_stats(ownname =>user ,tabname=>'WWFF' ,estimate_percent => 20,degree => 10,granularity => 'ALL',cascade => TRUE);

     

    ownname =>user   user 表示当前用户

    cascade => TRUE   true表示包括索引

  5. 分析该表所有信息(包括索引)

     

    analyze table wfxx compute statistics;

     

  6. 再次执行并查看

     

    select * from  wwff 

    where JGSJ>=to_date('2014-10-26 00:00:00','yyyy-mm-dd HH24:Mi:SS')

    and SJZT=1 and  FJBJ=3 and FJR=1 and rownum <= 1

    耗时:0.03秒

    收集完统计信息并分析表之后,发现sql 开始走索引了

    注意:只对表收集统计信息或者分析表信息,可能不会生效,必须两个都进行操作

    == END

 

posted on 2015-07-28 20:04  飄ぺ風  阅读(6254)  评论(0编辑  收藏  举报