set autotrace on 產生不準確的執行計劃
SQL> select count(*) from test;
COUNT(*)
----------
500000
SQL> select count(*) from test where id=498671;
COUNT(*)
----------
1
在id上有索引,顯然如果查where id=498671肯定會走索引:
SQL> exec :x :=498671
PL/SQL procedure successfully completed.
SQL> alter system flush shared_pool;
System altered.
SQL> set autot on
SQL> select * from test where id = :x;
ID NAME
---------- ------------------------------------------------------------
498671 498671
Execution Plan
----------------------------------------------------------
Plan hash value: 1357081020
--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 499K| 4386K| 269 (3)| 00:00:04 |
|* 1 | TABLE ACCESS FULL| TEST | 499K| 4386K| 269 (3)| 00:00:04 |
--------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter("ID"=TO_NUMBER(:X))
Statistics
----------------------------------------------------------
710 recursive calls
0 db block gets
116 consistent gets
0 physical reads
0 redo size
584 bytes sent via SQL*Net to client
469 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
10 sorts (memory)
0 sorts (disk)
1 rows processed
autotrace顯示的執行計劃是全表掃描,而實際的執行計劃真的如此嗎?
SQL> set autot off
SQL> select sql_id ,sql_text from v$sqlarea where sql_text like '%where id = :x%';
SQL_ID
-------------
SQL_TEXT
------------------------------------------------------------------------------------------------------------------------------------
32t8xz6c64um5
select sql_id ,sql_text from v$sqlarea where sql_text like '%where id = :x%'
8gaqs0a8u2327
select * from test where id = :x
f3b7q3xr8angs
EXPLAIN PLAN SET STATEMENT_ID='PLUS1053' FOR select * from test where id = :x
SQL> select * from table(dbms_xplan.display_cursor('8gaqs0a8u2327','','basic +peeked_binds'));
PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------
EXPLAINED SQL STATEMENT:
------------------------
select * from test where id = :x
Plan hash value: 2473784974
------------------------------------------------
| Id | Operation | Name |
------------------------------------------------
| 0 | SELECT STATEMENT | |
| 1 | TABLE ACCESS BY INDEX ROWID| TEST |
| 2 | INDEX RANGE SCAN | IDX_TEST |
------------------------------------------------
Peeked Binds (identified by position):
--------------------------------------
1 - :X (NUMBER): 498671
19 rows selected.
再來看不用繫結變數時autotrace顯示的執行計劃:
SQL> set autot on
SQL> select * from test where id =498671;
ID NAME
---------- ------------------------------------------------------------
498671 498671
Execution Plan
----------------------------------------------------------
Plan hash value: 2473784974
----------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
----------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 9 | 4 (0)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| TEST | 1 | 9 | 4 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | IDX_TEST | 1 | | 3 (0)| 00:00:01 |
----------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - access("ID"=498671)
Statistics
----------------------------------------------------------
1097 recursive calls
0 db block gets
201 consistent gets
0 physical reads
0 redo size
584 bytes sent via SQL*Net to client
469 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
27 sorts (memory)
0 sorts (disk)
1 rows processed
這一次是正確的執行計劃。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/10972173/viewspace-714889/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- sql中使用函式導致explain plan for和set autotrace得到執行計劃不準確SQL函式AI
- 開啟執行計劃set autotrace on
- 檢視sql執行計劃--set autotraceSQL
- 檢視sql執行計劃--set autotrace [final]SQL
- 使用set autotrace on 檢視資料庫執行計劃資料庫
- 怎樣得到準確的執行計劃
- 統計資訊不準確導致執行計劃走了笛卡爾積
- 獲取執行計劃之Autotrace
- 產生AWR及單個sql的執行計劃SQL
- 以autotrace檢視執行計劃時換行的解決
- 報錯的語句也可以產生執行計劃
- 如何讓Oracle產生預期的執行計劃(二)Oracle
- 如何讓Oracle產生預期的執行計劃(三)Oracle
- 如何讓Oracle產生預期的執行計劃(一)Oracle
- set autotrace的選項和計劃報告的屬性
- MES製造執行系統生產計劃管理
- 手工收集統計資訊及立即產生新的執行計劃
- ORACLE analyse table方式收集表統計資訊導致SQL執行計劃不準確而效能下降OracleSQL
- [20121212]謹慎使用set autotrace traceonly檢視執行計劃[補充].txt
- 看執行計劃是否正確
- 以scott使用者執行set autotrace 出錯
- 關於檢視Oracle資料庫執行計劃的命令(set autotrace的用法和含意及區別[轉])Oracle資料庫
- 生產環境使用10053分析Oracle的執行計劃Oracle
- autotrace 和explain plan for可能導致執行計劃錯誤AI
- Oracle 9i 開啟autotrace on 檢視執行計劃Oracle
- [20120112]謹慎使用set autotrace traceonly檢視執行計劃.txt
- AutoTRACE是分析SQL的執行計劃,執行效率的一個非常簡單方便的工具SQL
- 【顯示執行計劃】在普通使用者下使用set autot 檢視執行計劃
- 執行計劃不穩定的原因分析
- oracle 11g 基數反饋造成同一sql執行產生不同的執行計劃OracleSQL
- 一次ORACLE SQL謂詞跨界導致的執行計劃不準OracleSQL
- Oracle 開啟SQL跟蹤執行SET AUTOTRACE ON命令時出錯OracleSQL
- float計算不準確的替代方法
- set autotrace in SQL*PlusSQL
- 執行計劃-1:獲取執行計劃
- 分析執行計劃優化SQLORACLE的執行計劃(轉)優化SQLOracle
- 統計資訊不正確導致執行計劃的錯誤選擇
- 程式與執行緒的產生執行緒