[转] Oracle sql 查询突然变慢 -- 案例分析

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

 

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

步骤思路：

1：查看sql是否走索引

2：查看索引是否失效

3：hint 强制走索引（只是用来查看hint状态下，查询是否更改，应用是不能改的）

4：收集该表所有信息（包括索引）

5：分析该表所有信息（包括索引）

6：再次执行并查看

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

 

方法/步骤

1. 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. 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. 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. 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. 5

   分析该表所有信息（包括索引）

    

   analyze table wfxx compute statistics;

    

   步骤阅读
6. 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

 

转载于:https://www.cnblogs.com/fengaix6/p/4684206.html