今天重慶ORACLE社區有位哥們提問，為啥索引重建(alter index rebuil)之后，SQL變慢了，以前15秒就可以完成，現在要2分多種，于是問他要了執行計劃

SQL> set autotrace traceonly SQL> SELECT SEQ_PAY_CUSTOMEROPER.Nextval,u.ID,'admin',1,t.LAST_LOGIN_TIME,t.LOGIN_TIMES,t.LOGIN_IP2 FROM EFB_USER_MOVE@WODBLINK t,T_PAY_USERINFO u3 WHERE t.ID = u.ID AND u.ID > 3500000 AND u.ID<400000AND t.ID > 3500000 AND t.ID <= 40000004 /123832 rows selected.Execution Plan ---------------------------------------------------------- Plan hash value: 4225832519----------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Inst |IN-OUT| ----------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 77 | 5 (0)| 00:00:01 | | | | 1 | SEQUENCE | SEQ_PAY_CUSTOMEROPER | | | | | | | | 2 | NESTED LOOPS | | 1 | 77 | 5 (0)| 00:00:01 | | | |* 3 | INDEX RANGE SCAN| PK_T_PAY_USERINFO | 1 | 6 | 3 (0)| 00:00:01 | | | | 4 | REMOTE | EFB_USER_MOVE | 1 | 71 | 2 (0)| 00:00:01 | WODBL~ | R->S | -----------------------------------------------------------------------------------------------------------Predicate Information (identified by operation id): ---------------------------------------------------3 - access("U"."ID">3500000 AND "U"."ID"<=4000000)Remote SQL Information (identified by operation id): ----------------------------------------------------4 - SELECT "ID","LAST_LOGIN_TIME","LOGIN_TIMES","LOGIN_IP" FROM "EFB_USER_MOVE" "T" WHERE"ID"<=4000000 AND "ID">3500000 AND "ID"=:1 (accessing 'WODBLINK' )Statistics ----------------------------------------------------------86691 recursive calls18753 db block gets14781 consistent gets0 physical reads4035364 redo size5163224 bytes sent via SQL*Net to client91297 bytes received via SQL*Net from client8257 SQL*Net roundtrips to/from client0 sorts (memory)0 sorts (disk)123832 rows processed

這個SQL太簡單了，可以說是我見過的SQL中最簡單的，執行計劃也非常簡單。

這個SQL要返回123832條記錄，然后執行計劃走的是nested loops，問題顯而易見了，原因是表EFB_USER_MOVE是通過DBLINK過來的，本地無法得知表EFB_USER_MOVE的統計信息(也就是無法知道它有多少行)，所以CBO默認給它設置為1行，但是返回了123832條記錄，所以給這個SQL加了個HINT

SELECT /*+ full(u)*/ SEQ_PAY_CUSTOMEROPER.Nextval,u.ID,'admin',1,t.LAST_LOGIN_TIME,t.LOGIN_TIMES,t.LOGIN_IPFROM EFB_USER_MOVE@WODBLINK t, T_PAY_USERINFO uWHERE t.ID = u.IDAND u.ID > 3500000AND u.ID < 400000AND t.ID > 3500000AND t.ID <= 4000000;

這樣SQL就能幾秒跑完了，這里的sequence還值得注意，因為要返回123832條記錄，如果sequence上的cache很小，也必然導致SQL慢，建議設置cache到1000

總結：遇到SQL語句中要引用DBLINK，需要特別留意，通常這樣的SQL需要DBA添加HINT，其實這只是DBLINK中一個需要注意的地方，還有地方就是 有時候需要添加

????????????driving_site 這個HINT來優化，具體就不多說了。

轉載于:https://www.cnblogs.com/hehe520/archive/2011/11/01/6330560.html

總結

以上是生活随笔為你收集整理的DBLINK 无统计信息导致SQL变慢的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。