[轉] 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