转自：http://jingyan.baidu.com/article/8275fc868ce57946a03cf692.html
一条sql突然执行变慢，耗时9秒，应用是不能改的，只能从数据库方面下手解决
步骤思路：
1：查看sql是否走索引
2：查看索引是否失效
3：hint 强制走索引（只是用来查看hint状态下，查询是否更改，应用是不能改的）
4：收集该表所有信息（包括索引）
5：分析该表所有信息（包括索引）
6：再次执行并查看
注意：哪个用户执行较慢，就用哪个用户进行操作，这样才准确
方法/步骤
-
查看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 字段上已经创建了索引，查看执行计划，发现表没有走索引，进行全表扫描
-
查看索引是否失效
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'; --因为该表不是分区表
-
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走上索引
-
收集该表所有信息（包括索引）
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表示包括索引
-
分析该表所有信息（包括索引）
analyze table wfxx compute statistics;
-
再次执行并查看
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
